[MacPorts] #68640: clang-18: Undefined symbols on older OSes
MacPorts
noreply at macports.org
Fri Sep 27 07:38:53 UTC 2024
#68640: clang-18: Undefined symbols on older OSes
------------------------+----------------------
Reporter: snowflake | Owner: nobody
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords: haspatch
Port: clang-18 |
------------------------+----------------------
Comment (by markmentovai):
In [changeset:"70088c9cf4ce312082ecf721d7a4776df8b1eca7/macports-ports"
70088c9cf4ce312082ecf721d7a4776df8b1eca7/macports-ports] (master):
{{{
#!ConfigurableCommitTicketReference repository="macports-ports"
revision="70088c9cf4ce312082ecf721d7a4776df8b1eca7"
clang-15: Move libc++*.* libraries to libc++ sub-dir, fix install names
This applies a1d4865220b5, which addressed this for clang-16–18 for
https://trac.macports.org/ticket/68640, to clang-15, to fix a bug
observed while running clang-15 as a linker driver on macOS 15.
When running as a linker driver, clang provides ld with clang’s own LTO
plugin by invoking ld with `-lto_library
${PREFIX}/libexec/llvm-15/lib/libLTO.dylib`. Upon receipt of these
arguments, Xcode ld currently loads the plugin by re-`execve`ing itself
with DYLD_LIBRARY_PATH=${PREFIX}/libexec/llvm-15/lib in effect, causing
dyld to prefer libLTO.dylib in that directory over the
@rpath/libLTO.dylib that ld requests to load via a Mach-O load command.
With DYLD_LIBRARY_PATH in effect, dyld can potentially use any other
module in that same directory to satisfy any other Mach-O load command.
In this case, the directory contained both libc++.dylib and
libc++abi.dylib from clang, and dyld used these to replace the libraries
of the same name ordinarily provided by the OS in /usr/lib (via the dyld
shared cache). This is undesirable in general, but occurred silently on
macOS < 15. It became noticeable on macOS 15 because system libraries
that depend on libc++abi.dylib now reference symbols that are present in
the system’s version, but not in clang’s, causing messages such as
dyld[60301]: symbol '__ZnwmSt19__type_descriptor_t' missing from root that
overrides /usr/lib/libc++abi.dylib. Use of that symbol in
/usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.
dyld[60301]: symbol '__ZdlPvSt19__type_descriptor_t' missing from root
that overrides /usr/lib/libc++abi.dylib. Use of that symbol in
/usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.
repeated for every system library that references those symbols. These
messages warn of potential run-time bugs due to dyld intentionally
mis-resolving the missing symbols.
As clang should not seek to replace the system’s libc++ with its own in
system libraries, this was a latent problem even pre-macOS 15.
The workaround moves clang’s libc++ libraries to a new subdirectory,
${PREFIX}/libexec/llvm-15/lib/libc++, where they will not be found or
used even with DYLD_LIBRARY_PATH set to ${PREFIX}/libexec/llvm-15/lib as
it is when clang runs the linker.
This also contains a fix for the LC_INSTALL_NAMEs of libc++.dylib and
libc++abi.dylib, which should have been recorded as @rpath-relative, but
due to an error in the Portfile’s handling of CMAKE_INSTALL_NAME_DIR,
were instead recorded using absolute paths rooted at
${PREFIX}/libexec/llvm-15/lib. When the libraries were moved elsewhere,
they tripped MacPorts’ check for linking errors due to libc++.dylib’s
dependency on libc++abi.dylib at a path where it was no longer
installed. Discussion at
https://github.com/macports/macports-
ports/pull/25918#issuecomment-2377971503.
This is an observable change in the installed clang-15 package, but the
revision is not being bumped in this commit because this change is being
merged atomically in #25918 with another change that updates clang-15’s
revision.
References: https://trac.macports.org/ticket/70779
}}}
--
Ticket URL: <https://trac.macports.org/ticket/68640#comment:62>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list