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

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.

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.

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