[MacPorts] #62426: libc++: using a newer libc++ to build software on older macos systems

[MacPorts]

#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):

 update.

 I have rebuilt llvm-12 and clang-12 twice (the former more out of
 conscience but with a small config tweak) so that the install corresponds
 to what was done up till at least LLVM 9. The libc++ and libc++abi headers
 are prepared, but libc++ itself isn't built and neither of these libraries
 gets installed (via a +no_libcxx variant).

 Thus, clang++-mp-12 will built code against the v12 libc++ headers but
 link against whichever libc++ binary it will find.

 I did this twice, in fact (clang-12 takes almost 6h to build on my system,
 but fortunately I used ccache):

 1) against the system's libc++ (current_version 120.x.y). With this I can
 still reproduce what you see with clang-14.

 2) against my own libc++ (current_version 9.0.1). Same conclusion though
 the situation is now reversed: behaviour of the test app is only correct
 when linked against my own libc++.

 It would seem thus that code that depends on libLLVM needs to be linked
 against the same libc++ as libLLVM is linked, which confirms what you have
 been saying. The difference must be in libLLVM; remember that my builds
 all use the libc++ *headers* that come with the compiler and that building
 with clang-12 but against the libraries of llvm-9 does create the issue.
 So to be really exhaustive someone would need to check with clang-10 and
 clang-11 to know at which major version this change was introduced, in
 case there are older systems where that information could be useful to
 keep things simpler.

 What annoys me is that injecting libc++ via DYLD_INSERT_LIBRARIES does not
 seem to have an effect on this ... and that *apparently*
 /usr/lib/libc++.1.dylib is being filtered out from the list of open files
 (blame the dyld cache??).
 Injecting libc++ (and libc++abi) via DYLD_INSERT_LIBRARIES *used* to have
 an effect; in the past it allowed me to prevent warnings from appearing in
 the system.log and/or on the calling terminal when running KDE4
 applications. It's possible that was on OS X 10.6 though.

 All this does indeed not speak for installing a full libc++ library in
 $prefix/lib

 So is this an ODR issue? Probably, but for now it's one that appears to be
 limited to llvm/clang libraries. I have some applications that use
 libClang, I will have to check if that library is concerned too.

 I've pushed the changes to my macstrop:libcxx and macstrop:llvm-12 ports
 so you can check what I did exactly. It is my intention to check what
 happens when I 1) generate a local libc++ with current_version higher than
 the system lib's (will DYLD_INSERT_LIBRARIES have more effect?) and 2)
 update my libc++ to v12.0.1 .

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