<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap;" class="">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.
</pre><hr class=""><ul class=""><br class=""></ul></blockquote><br class=""><div class="">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. :></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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”.</div><div class=""><br class=""></div><div class="">And then a bit of a slap for still being on 10.6.8, don’t you know that is insecure, etc.</div><div class=""><br class=""></div><div class="">So I dropped all of that line of discussion a year or two ago.</div><div class=""><br class=""></div><div class="">Ken</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>