libcxx 8+ usability

[RJVB (René Bertin)]

I just saw this

Starting with LLVM 8.0.0, users that wish to link together translation units built with different versions of libc++’s headers into the same final linked image MUST define the _LIBCPP_HIDE_FROM_ABI_PER_TU macro to 1 when building those translation units. Not defining _LIBCPP_HIDE_FROM_ABI_PER_TU to 1 and linking translation units built with different versions of libc++’s headers together may lead to ODR violations and ABI issues. On the flipside, code size improvements should be expected for everyone not defining the macro.

(​https://releases.llvm.org/8.0.0/projects/libcxx/docs/ReleaseNotes.html)

I interpret this as "define _LIBCPP_HIDE_FROM_ABI_PER_TU if you want to use the libc++ headers to build code that will link against system libraries".

A really strange decision if that interpretation is correct but if it is correct wouldn't it be a least-worst idea revert the logic in c++/v1/__config to avoid having to add -D_LIBCPP_HIDE_FROM_ABI_PER_TU to just about every C++ compiler invocation?

[kencu (Ken)]

I am still trying to fully wrap my head around this one.

[RJVB (René Bertin)]

I think it implies that you need to revbump all dependents each time port:libcxx is updated on systems where it replaces the system C++ runtime.

[kencu (Ken)]

but if you did update and replace libcxx to > 7 on an older system, all the system software would break, I guess...not sure just now.

if we ever do try to update libcxx to > 7, we better be very careful.

[RJVB (René Bertin)]

Well, that would depend on the older system, and how you use the port. Systems that came with libc++ would be concerned but only if you actually build against the libc++ 8 headers. I don't think even clang 8+ would do that (on Mac) unless instructed to do so explicitly. I think each clang version does use its own C++ headers on Linux, so I'll kick some tyres there to see what happens.

On even older systems that didn't come with libc++ the system libraries were built against libstdc++, and we have to assume those will continue to work with userland libraries built against libc++ 8+. It's on these systems that problems may arise if you don't rebuild each and every port that depends on port:libcxx

I have my own port:libcxx version which is already at 8.0.0, and I actually use DYLD_INSERT_LIBRARIES to load the new libc++ instead of the system runtime, and that works fine (but I built libc++ with clang 5 or clang 6).

[RJVB (René Bertin)]

Replying to RJVB:

I think each clang version does use its own C++ headers on Linux, so I'll kick some tyres there to see what happens.

Apparently it doesn't, but it does use the C++1x headers from the libc++ install (/usr/include/c++/v1). On first glance I don't notice any issues, but I think there was no actual passing along of relevant data structures between the different translation units. I'm now rebuilding a host app with clang++-5.0 -stdlib=libc++ and one of its more complex plugins with clang++-8 -stdlib=libc++, if that doesn't trip any of the more obvious (potential) taboos I don't know what would...

Or, the quote above only actually pertains to libc++ 8 and up, regardless of the clang/llvm version with which it is used. In that case my tyre kicking is pointless because everything I have built with clang++ -stdlib=libc++ must have been (re)built against libc++ 8.0.0 already...

[kencu (Ken)]

There is a LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT setting that can be used when libcxx is built that hopefully changes the default behaviour, as it promises to do.

[mascguy (Christopher Nielsen)]

Adding Kirill, in case he's interested