port:libcxx - why so old

Ken Cunningham ken.cunningham.webuse at gmail.com
Sun Nov 28 20:30:21 UTC 2021


> Hi,
> 
> Judging from the version number, port:libcxx ships a version that's long outdated. Is there a reason for that, like it's the latest version that builds on all OS X versions that require the libc++ conversion?
> 
> I have a local version that is currently at v8.0.0 on my 10.9.5 system and have had that install the runtime shared libraries (= not the ones used by the linker) in $prefix/lib via an additional +runtime variant which also installs a launch wrapper that adds $prefix/lib to DYLD_INSERT_LIBRARIES (DYLD_LIBRARY_PATH typically isn't enough on Mac). It's a lot newer than my system versions even (than v5.0.1) and yet I can't recall having had any issues with it. On the contrary, it fixed a number of strange C++ runtime warnings in certain KDE software and must give me that bit more performance because built with a more recent clang, full CPU-specific optimisation and LTO.
> 
> R.
> 

libcxx 5.0 is quite new in fact — it supports libcxx features that only show up in 10.13+ (which give us the strange fact of ports that build on 10.6, and 10.13+, but nothing in between. :>

I had libcxx 7.0 ready to push, which I was going to do if I ever sorted out how to bootstrap it to the full Thread_Local_Storage supporting version without tricks.

But I never noticed a single port that built with libcxx 7.0 that would not build with libcxx 5.0, so there was no big rush.

I did replace the libc++.dylib on my 10.7.5 system with the one from llvm-5.0 and promptly found certain applications (ical, for example) crashing regularly.

So I gave up on the plan of a blanket replacement, and came up with macports-libcxx instead, which had more general use across the entire lineup of systems.


There are definite ABI changes between libcxx versions. It is 100% not guaranteed that things that are built against libcxx-11.0 will work with things built against libcxx-5.0, or the system libcxx, and there are known examples I have worked through with upstream where such backward incompatibility caused errors, and was specifically never going to be fixed by upstream.

The exact comment was something like: “We don’t want to encourage people to think this should work, so we won’t support any fixes for it”.

And then a bit of a slap for still being on 10.6.8, don’t you know that is insecure, etc.

So I dropped all of that line of discussion a year or two ago.

Ken




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20211128/e94591f7/attachment-0001.htm>


More information about the macports-dev mailing list