Bug 215193 - libc++ and libcxxrt: convert to a private library
Summary: libc++ and libcxxrt: convert to a private library
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords: feature
Depends on: 215192
Blocks:
  Show dependency treegraph
 
Reported: 2016-12-10 08:50 UTC by Jan Beich
Modified: 2020-07-29 03:32 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2016-12-10 08:50:30 UTC
libc++ version is currently tied to a specific FreeBSD release. If third-party software depends on bleeding edge C++ features it may fail to build. And pulling newer version from ports is risky due to ABI mismatch. To avoid Perl-style blunder let's promote the port version instead.

For example, FreeBSD 10.x cannot benefit from complete C++14 support.
Comment 1 Jan Beich freebsd_committer 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 freebsd_committer 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.
Comment 3 Henry Hu 2018-05-10 00:54:39 UTC
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 freebsd_committer 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.