> On Nov 28, 2021, at 12:30 PM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: > >> 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 > >
Oh, BTW you can build our libcxx-5.0 with any compiler you want to — we do already get LTO, but if you want to build it with clang-9.0, or clang-13 to see if you get even newer super-duper LTO on steroids or something, go ahead. I did build it with clang-9.0 I think; I haven’t tried with clang 13, but it would probably build. The real change in libcxx (I think it was you who pointed it out in fact) that was likely to break libcxx against the system libc++.dylib software was around llvm-8.0. Somewhere there is a ticket where you pointed that out. So that’s why I never personally tried a full replacement with libcxx-8.0, and left it libcxx-7.0 at the most (for my personal systems). Ken
