[MacPorts] #63725: qt5-qtwebengine @5.15.2 build error on Monterey

MacPorts noreply at macports.org
Wed Dec 1 20:18:53 UTC 2021


#63725: qt5-qtwebengine @5.15.2 build error on Monterey
------------------------------+---------------------------------
  Reporter:  amake            |      Owner:  MarcusCalhoun-Lopez
      Type:  defect           |     Status:  assigned
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:
Resolution:                   |   Keywords:
      Port:  qt5-qtwebengine  |
------------------------------+---------------------------------

Comment (by chrstphrchvz):

 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)`).

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/63725#comment:12>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list