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

 A while back ago already I found this, which I copied into my port:libcxx
 version as a comment:

 {{{
 # FUTURE WARNING:
 # Starting with LLVM 8.0.0, users that wish to link together translation
 units built
 # with different versions of libc++'s headers into the same final linked
 image MUST
 # define the _LIBCPP_HIDE_FROM_ABI_PER_TU macro to 1 when building those
 translation
 # units. Not defining _LIBCPP_HIDE_FROM_ABI_PER_TU to 1 and linking
 translation units
 # built with different versions of libc++'s headers together may lead to
 ODR violations
 # and ABI issues. On the flipside, code size improvements should be
 expected for
 # everyone not defining the macro.
 }}}

 Looks like it could be a good idea to set that macro too in the `__config`
 file where you disable the availability conditional. I'll be doing that in
 my implementations from now on.

 Sadly I can't say I'm surprised that any project in which Apple are a big
 player doesn't bother with backwards compatibility... (just like I can't
 be bothered to memorise which fancy name goes with what OS version? ;) )

 And yeah, if that's their mindset I can imagine that the likelihood of
 issues is going to increase when you "override" a v8.0.0+ libc++ with a
 newer version. You'd hope that Apple build their libraries with the above
 macro defined, at least.

 But again, I've been injecting libc++ 8.0 to override OS 10.9.5's libc++
 for a few years now, in highly complex applications like KDevelop5. Never
 an issue that I do not also see on Linux.

 BTW, I do patch the libc++* CMake files so that the dylibs have a
 `current_version` set that corresponds to the actual LLVM version.

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