> 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