[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:  assigned
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:
 Keywords:               |       Port:  libcxx
-------------------------+----------------------
 As libc++ evolves, software uses new libc++ features.

 Older systems have a system libc++ version in {{{/usr/lib/libc++.dylib}}}
 and a matching {{{/usr/lib/libc++abi.dylib}}} there as well. These
 versions cease being updated by Apple at a certain point in the lifespan
 of the OS version.

 By default, the clang linker driver will use this libc++, assuming
 {{{-stdlib=libc++}}} has been set (it is set by default by the linker
 driver if no other stdlib option is specified).

 The current {{{libcxx}}} port has the ability to build a new libc++
 (presently corresponding to llvm-5.0). On SnowLeopard and earlier
 (Leopard, TIger), this libc++.dylib is used, and in so doing, provides
 those OS versions with a quite new libc++.dylib.

 On newer systems, there is a variant available for libcxx:
 {{{
 $ port variants libcxx
 libcxx has the variants:
    replacemnt_libcxx: EXPERTS ONLY: Build a replacement libcxxabi and
 libcxx even if it is already part of the base OS.
 }}}

 this builds a libc++/libc++abi that could use to replace the libc++ in
 {{{/usr/lib/libc++*.dylib}}} to get newer libc++ features.

 I have done this, on Lion, and it does work, although it is not
 particularly well tested to be sure.

 More reasonable would be a parallel libc++ that could be used if needed
 (much like we have a libstdc++ installed with newer versions of libgcc
 that can be used if needed). This is undoubtedly more palatable than
 replacing the system libc++.dylib to the vast majority of users.

 To facilitate this, a  newer libc++ is now installed with the clang-11
 port, here by default:
 {{{
 $ port contents clang-11 | grep libc++
   /opt/local/libexec/llvm-11/lib/libc++.1.0.dylib
   /opt/local/libexec/llvm-11/lib/libc++.1.dylib
   /opt/local/libexec/llvm-11/lib/libc++.a
   /opt/local/libexec/llvm-11/lib/libc++.dylib
   /opt/local/libexec/llvm-11/lib/libc++abi.1.0.dylib
   /opt/local/libexec/llvm-11/lib/libc++abi.1.dylib
   /opt/local/libexec/llvm-11/lib/libc++abi.a
   /opt/local/libexec/llvm-11/lib/libc++abi.dylib
   /opt/local/libexec/llvm-11/lib/libc++experimental.a
 }}}

 By default, by the llvm build system, these dylibs have @rpath linkages:
 {{{
 $ otool -L /opt/local/libexec/llvm-11/lib/libc++.dylib
 /opt/local/libexec/llvm-11/lib/libc++.dylib:
         @rpath/libc++.1.dylib (compatibility version 1.0.0, current
 version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1252.250.1)
         @rpath/libc++abi.1.dylib (compatibility version 1.0.0, current
 version 1.0.0)
 }}}

 (This type of linkage could easily be changed to a full path linkage with
 one or two lines of code in the portfile, should it prove beneficial to do
 so.)

 This ticket will explore how we might use this newer libc++.dylib in ports
 that require newer libc++ features on older systems.

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