what's with the C++ <filesystem> extension?

[René J.V. Bertin]

On Monday September 19 2022 13:56:01 Chris Jones wrote:

>But anyway, I m sure you will think you are right, so please feel free to experiment on your own system, as you get to own the pieces there once it breaks.

What do you think happens when you upgrade an OS but not ALL your other software?

Libc++ isn't something that is magically different from other libraries.

Check the libcxx sources. There's an option to build it against the v1 or the v2 ABI. As long as the v1 ABI is available you can at least run applications built against an older libc++ version using a later version of the v1 ABI. Just like with any other library. If you read my initial post attentively you will realise that this is exactly what I have been doing for years now (and in case it wasn't clear, I do mean I install the libs under $prefix/lib!).
I do not currently install a libc++.dylib, but I will start experimenting with this: it should just mean that any new code I build will find the implementation for functions that are declared by the headerfiles (and not marked as unavailable). Any catastrophic failure will be limited to those ports, not to my system

In fact: the libc++ headerfiles for libc++ vX are installed with port:clang-X so anything built with that compiler will assume to find the implementation of functions declared in those headers, but will also use the ABI of that version! We can use the system libc++ with a much newer clang version for 2 reasons:
- the LLVM devs take care not to modify the ABI except possibly in backwards-compatible ways (like Qt also guarantee) allowing you to use newer libc++ headers (and thus structures/classes) with an older libc++ binary
- Apple marks newer functions as available from a certain OS version only. Sooner or later they will miss a function because I doubt they test every feature in every new clang/llvm version on ever previous version of the OS where it can be built.

Now, if someone knows off the top of their heads which libc++ version was shipped with OS 10.15.0 I'd appreciate not having to hunt down that information myself - thanks!

R.

PS: I've updated my port:libcxx from v5 to v6.0 to v6.0.1 to v8.0.0 without rebuilding a single port. And FYI, on Linux I do install libc++.so (= the linker interface library, in /usr/lib because there's no conflict there) and I have been building a certain number of my ports with a +libcxx variant that does what I hope must be evident. Those too did not require a rebuild after upgrading libc++.