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

MacPorts noreply at macports.org
Sun Mar 14 19:56:12 UTC 2021


#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:
Resolution:               |   Keywords:
      Port:  libcxx       |
--------------------------+----------------------

Comment (by kencu):

 I will be creating a new port, so as not to collide with or confuse the
 existing libcxx port, which has it's own purposes at present and is deeply
 rooted in base right now. We can call this new port anything we like, eg.
 macports-libcxx (that has a nice ring).

 It copies the c++ headers and libc++ dylibs from the clang-11 port, and
 gives them proper full path linkage names in the /opt/local/include and
 /opt/local/lib directories.

 Then we use something like this in the Portfile, eg mkvtoolnix:
 {{{
 if {${os.platform} eq "darwin" && ${os.major} < 19} {
     # requires a newer libc++ than the system can provide
     configure.cppflags-append -D_LIBCPP_DISABLE_AVAILABILITY
     configure.cxxflags-append  -nostdinc++ -I${prefix}/include/libcxx/v1
     configure.ldflags-append  -L${prefix}/lib/libcxx
     compiler.blacklist-append {clang < 1100} {macports-clang-3.[3-9]}
 {macports-clang-[5-8].0}
 }
 }}}

 and we get a binary that works, and is linked as we expect it to be
 linked:
 {{{
 $ otool -L /Applications/MacPorts/MKVToolNix.app/Contents/MacOS/MKVToolNix
 /Applications/MacPorts/MKVToolNix.app/Contents/MacOS/MKVToolNix:
     /opt/local/lib/libcxx/libc++.1.0.dylib (compatibility version 1.0.0,
 current version 1.0.0)
     ... etc ...
 }}}
 On reasonably recent systems, there is not likely to be much ODR trouble,
 as the libc++ is very similar. As the ages between the system libc++ and
 the one we are using diverge, probability of trouble increases, I would
 think.

 As before, it would be possible to make a new {{{-stdlib=macports-
 libc++}}} for clang, but that (at present) sounds like more trouble than
 it's worth, with all the changes to base etc that might be needed.

 We also have the option of using DYLD_LIBRARY_PATH to force everything to
 use the new libc++ (like we do in the legacysupport 1.1 PG for libstdc++)
 but that has it's own chances of troubles.

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


More information about the macports-tickets mailing list