[MacPorts] #68219: qt5-qtbase @5.15.10_1: dyld: Symbol not found: __ZNSt3__13pmr15memory_resourceD2Ev

MacPorts noreply at macports.org
Fri Sep 22 01:56:55 UTC 2023


#68219: qt5-qtbase @5.15.10_1: dyld: Symbol not found:
__ZNSt3__13pmr15memory_resourceD2Ev
--------------------------+---------------------------------
 Reporter:  chrstphrchvz  |      Owner:  MarcusCalhoun-Lopez
     Type:  defect        |     Status:  assigned
 Priority:  Normal        |  Milestone:
Component:  ports         |    Version:  2.8.1
 Keywords:                |       Port:  qt5-qtbase
--------------------------+---------------------------------
 Building with the macOS 14.0 SDK (from Xcode 15 command line tools) on
 macOS 13 Ventura encounters a runtime linker error:

 {{{
 /opt/local/var/macports/build/_opt_local_var_macports_sources_mse.uk.rsync.macports.org_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtbase/work
 /qtbase-everywhere-src-5.15.10/src/gui/qvkgen_wrapper.sh vulkan/vk.xml
 /opt/local/var/macports/build/_opt_local_var_macports_sources_mse.uk.rsync.macports.org_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtbase/work
 /qtbase-everywhere-src-5.15.10/header.LGPL vulkan/qvulkanfunctions
 dyld[69446]: Symbol not found: __ZNSt3__13pmr15memory_resourceD2Ev
   Referenced from: <CB507A0E-7858-358A-A4C4-D8023DF6627A>
 /opt/local/var/macports/build/_opt_local_var_macports_sources_mse.uk.rsync.macports.org_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtbase/work
 /qtbase-everywhere-src-5.15.10/lib/QtCore.framework/Versions/5/QtCore
   Expected in:     <8B258FAF-4392-3385-A019-D80F49C5AF31>
 /usr/lib/libc++.1.dylib
 make[2]: *** [vulkan/qvulkanfunctions.h] Abort trap: 6
 }}}

 It seems similar to #67980 where the build is erroneously assuming runtime
 availability of C++17 `<memory_resource>`, which is not the case before
 macOS 14 Sonoma. I am not aware if this vulkan-related target is supposed
 to be built despite intentionally passing `-no-feature-vulkan` to
 configure.

 Using `configure.sdk_version=13.3` fails to work around the issue,
 apparently because some steps use `-isysroot
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk`, which now points to
 MacOSX14.0.sdk; maybe this is due to `-sdk macosx` being intentionally
 passed to the configure script to avoid hardcoding a specific SDK version
 in installed files.

-- 
Ticket URL: <https://trac.macports.org/ticket/68219>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list