Bug 215193

Comment 1 Jan Beich 2016-12-10 09:24:27 UTC

Another issue is on libc++-enabled systems libstdc++ from ports cannot be used. theraven@ proposed to link libstdc++ against libcxxrt (like in gcc42 case) but that often requires bleeding edge version of it. 11.0+ release model should accelerate updates adoption but relying on libsupc++ compatibility still leaves some gaps as FreeBSD tries to maintain ABI instead of leaving it to upstream.

Comment 2 David Chisnall 2016-12-10 11:09:13 UTC

I think that a better solution to this would be more frequent upstream imports into base (which should become a lot easier to push to users once we have packaged base).  Making libc++ a private library would mean that it would not be possible for users to compile C++ programs without installing a port, which would be a major regression.  If we did that, then there's little point having a C++ compiler in the base system at all.

Libc++ aims to be backwards binary compatible, and so there shouldn't be any POLA violations from installing a newer one.

Can we create/revive the libc++ port? We can still have the base version, but we can also allow people to install the port version, and let other ports depend on it. When compiling dependent ports, compiler flags can be set to use the header file from the port, and link with the libc++ library from the port. During runtime, the port version can use libmap.conf to redirect every program to use the library from the port.

Comment 4 David Chisnall 2018-05-10 16:01:00 UTC

(In reply to Henry Hu from comment #3)

That should be fine, as long as there aren't any ABI compatibility problems between the different versions.  The problem comes when two libraries used by the same program both use libc++ and end up with different versions.  As long as it's fine for both to use the newer one (which it should be with libc++) then that's fine.

We will likely to a libc++ ABI break in 12.0, but that's probably not a good idea for the port running on 11.

(In reply to David Chisnall from comment #2)

For reference:

https://releases.llvm.org/13.0.0/projects/libcxx/docs/DesignDocs/ABIVersioning.html

reports .  . .

QUOTE
Libc++ aims to preserve a stable ABI to avoid subtle bugs when code built under the old ABI is linked with code built under the new ABI. At the same time, libc++ wants to make ABI-breaking improvements and bugfixes in scenarios where the user doesn’t mind ABI breaks.

To support both cases, libc++ allows specifying an ABI version at build time. The version is defined with CMake option LIBCXX_ABI_VERSION. Currently supported values are 1 (the stable default) and 2 (the unstable “next” version). At some point “ABI version 2” will be frozen and new ABI-breaking changes will start being applied to version 3; but this has not happened yet.

To always use the most cutting-edge, most unstable ABI (which is currently 2 but at some point will become 3), set the CMake option LIBCXX_ABI_UNSTABLE.

Internally, each ABI-changing feature is placed under its own C++ macro, _LIBCPP_ABI_XXX. These macros’ definitions are controlled by the C++ macro _LIBCPP_ABI_VERSION, which is controlled by the LIBCXX_ABI_VERSION set at build time. Libc++ does not intend users to interact with these C++ macros directly.
END QUOTE