[MacPorts] #62426: libc++: using a newer libc++ to build software on older macos systems
MacPorts
noreply at macports.org
Mon Sep 19 16:24:48 UTC 2022
#62426: libc++: using a newer libc++ to build software on older macos systems
-------------------------------------+--------------------
Reporter: kencu | Owner: kencu
Type: enhancement | Status: closed
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: fixed | Keywords:
Port: libcxx macports-libcxx |
-------------------------------------+--------------------
Comment (by RJVB):
Replying to [comment:32 kencu]:
> That is called an ODR violation, and it is the primary concern with this
process, for sure.
>
Somehow I missed this discussion (and new port, which is a more evolved
version of something I've been doing for years now; installing a newer
libc++.1.dylib in $prefix/lib).
I don't think we have to worry about ODR violations as long as
- shared libraries are used
- libcxx provides the v1 ABI and we make sure to use it (there's a CMake
option to select the ABI version)
- users don't activate an older version of libc++
Under those conditions, a binary that is linked against our libc++ will
almost certainly load it before the system libc++, and that *should*
prevent the system version from being loaded, just as when you used
DYLD_INSERT_LIBRARY. Thus, binaries like system frameworks that were
linked against the system version will end up using the newer version, and
that should work just like with any other library. Despite its crucial
role, libc++ is not different in this, there's nothing magical about it.
If this backwards ABI compatibility were not guaranteed Apple couldn't
update the system libc++ without obliging users to update or rebuild all
their applications.
--
Ticket URL: <https://trac.macports.org/ticket/62426#comment:39>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list