port:libcxx - why so old

[Ken Cunningham]

> On Nov 28, 2021, at 12:30 PM, Ken Cunningham <ken.cunningham.webuse at 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

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