> 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




Reply via email to