Changes between Version 1 and Version 2 of Ticket #63725, comment 12


Ignore:
Timestamp:
Dec 10, 2021, 11:53:43 AM (2 years ago)
Author:
chrstphrchvz (Christopher Chavez)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #63725, comment 12

    v1 v2  
    1 I may have identified a workaround for this issue. Compiling src/3rdparty/chromium/base/strings/string16.cc separately (by adding it to `jumbo_excluded_sources` in src/3rdparty/chromium/base/BUILD.gn) outputs src/core/release/obj/base/base/string16.o, which appears to reliably contain `base::string16::reserve(unsigned long)`. `shrink_to_fit()`, `reserve()`, and `reserve(0)` are equivalent in C++17 and earlier (various versions of libc++ have even implemented `shrink_to_fit()` as `reserve()` or vice versa in the include/c++/v1/string header file). Since string16.cc is currently being compiled with `-std=c++14`, I would try replacing `dest_str->shrink_to_fit()` with `dest_str->reserve(0)` in src/3rdparty/chromium/base/strings/utf_string_conversions.cc (~~I don’t know if it looks silly to do `reserve(0)` right after doing `reserve(dest_len32)`~~ misread `resize(dest_len32)`, which would not be the same as `reserve(dest_len32)`).
     1I may have identified a workaround for this issue. Compiling src/3rdparty/chromium/base/strings/string16.cc separately (by adding it to `jumbo_excluded_sources` in src/3rdparty/chromium/base/BUILD.gn) outputs src/core/release/obj/base/base/string16.o, which appears to reliably contain `base::string16::reserve(unsigned long)`. `shrink_to_fit()`, `reserve()`, and `reserve(0)` are equivalent in C++17 and earlier (various versions of libc++ have even implemented `shrink_to_fit()` as `reserve()` or vice versa in the include/c++/v1/string header file). Since string16.cc is currently being compiled with `-std=c++14`, I would try replacing `dest_str->shrink_to_fit()` with `dest_str->reserve(0)` in src/3rdparty/chromium/base/strings/utf_string_conversions.cc (~~I don’t know if it looks silly to do `reserve(0)` right after doing `reserve(dest_len32)`~~ edit: misread `resize(dest_len32)`, which would not be the same as `reserve(dest_len32)`).
    22
    3 I’m not sure what the right conditions are for getting string16.o to contain a symbol for `base::string16::shrink_to_fit()`. So far the only way I’ve managed to do so is to add a dummy function `void Dummy(string16& str) { str->shrink_to_fit(); }` to `base::string16_internals` in string16.cc (with corresponding declaration in string16.h), and compile string16.cc with the macOS 10.15 SDK. The clang version/vendor did not seem to matter (tried Xcode clang 13.2, MacPorts LLVM clang 9, and MacPorts LLVM clang 11); maybe that suggests this is more likely to be a libc++ bug in the macOS 12 SDKs.
     3I’m not sure what the right conditions are for getting string16.o to contain a symbol for `base::string16::shrink_to_fit()`. ~~So far the only way I’ve managed to do so is to add a dummy function `void Dummy(string16& str) { str->shrink_to_fit(); }` to `base::string16_internals` in string16.cc (with corresponding declaration in string16.h), and compile string16.cc with the macOS 10.15 SDK. The clang version/vendor did not seem to matter (tried Xcode clang 13.2, MacPorts LLVM clang 9, and MacPorts LLVM clang 11); maybe that suggests this is more likely to be a libc++ bug in the macOS 12 SDKs.~~ Edit: I don’t think I was careful with which version I used for different steps. I think it may make a difference since MacPorts’ clang seems to use its own libc++ headers by default.