Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?

[Charlie Li]

Mark Millard wrote:

FreeBSD has the property that the only implementation of (modern,
clang based) libc++ is the one provided by the system. Having
the ports environment have its devel/llvm* contexts use their own
libc++ that might not match or be compatibile with the system
libc++ is not provided for currently, as I understand.

But, as far as I can tell, it looks unlikely that the system libc++
would be configured to allow import std or import std.compat :
There looks to be extensive compiler options matching requirements
for how the supplied std and std.compat were set up before they
can be used. Building FreeBSD itself may have no intended use of
the likes of import std or import std.compat .

This leads me to wonder if FreeBSD will enable alternate libc++
usage for ports at some point in order to allow ports to use import
std and/or import std.compat . Might that need, say, a lang/clang++*
separate from the devel/llvm* ? Likely not intended for building
FreeBSD itself?

A problem here is avoiding he need for any process to have multiple
libc++ implementations. This might be messy enough to block use of
import std or import std.compat in ports fairly generally, needing a
from scratch bulk -a run that is overall based on a specific
alternate libc++ for example. (May be only those folks building
there own packages/ports get to do such?)

At least in ports, GCC and anything built with it already uses its own libstdc++ which is separate from base system libc++ based on LLVM. I imagine other C++ compilers (that have been ported, output functional binaries, but may not be in the ports tree) have similar deals.

--
Charlie Li
...nope, still don't have an exit line.

While you're talking about std and std.compat, I have a related issue whilst working on the www/webkit2-gtk update. They have code that relies on a std::pair implementation/ABI that does not work with our base system libc++. This is because our base system uses LLVM libc++ ABI version 1, but the needed implementation is in ABI version 2, which they have still (even in trunk!) not declared stable. Meanwhile libstdc++ works fine. Given the complexity of WebKit (and browser rendering engines generally anymore) and balancing maintenance considerations, using GCC/libstdc++ for this port is most likely inevitable. So to answer your question, using other C++ Standard Library implementations, particularly with other compilers, already happens in ports, but not at a general/blanket level.

OpenPGP_signature.asc
Description: OpenPGP digital signature