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

 Replying to [comment:66 RJVB]:
 > have you tried with the PER_TU macro discussed above?

 I just used the stock installs, and (after getting my fingers thoroughly
 rapped by upstream for suggesting it) have not used the PER_TU macro as
 yet.

 >
 > Why is libc++ being built and installed with the newer clang versions?
 From what I understand it shouldn't be used and will not under normal
 circumstances provide new functionality anyway?

 It was added to the default clang build to simplify creating the macports-
 libcxx port for one, and to allow testing by interested folks such as
 yourself :> You're welcome!


 >
 > BTW, did you notice that you have both
 >
 > `     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
 version 1.0.0)`
 >
 > and
 >
 > `/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
 1200.3.0)`
 >
 > (look at the current_version!) which seems a bit odd?

 that seems to have happened after I used install_name_tool to switch the
 libc++ reference. I guess it doesn't pick up the correct current version.
 These tools do kind weirder things since dyld_shared_library_cache, I
 find, as the files don't exist at all any more.



 > I realise that Apple's stubborn use of unrelated version numbers could
 wreak havoc on appropriate use of self-built library versioning; do we
 have a table mapping their version numbers to/from the stock LLVM/libc++
 versions?

 It's not a clean mapping. At last count, Apple was carrying something like
 12,000 patches for xcode on top of the LLVM tree, or some similar number.
 So their versions are not quite llvm's versions.

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