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

On Jul 29, 2024, at 07:54, Charlie Li <[email protected]> wrote:

> 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.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020
does not yet list a version for its "Standard Library Modules std and
std.compat" entry in its "Table 1.10. C++ 2023 Library Features". So it
will be a while before both clang++ and g++ have support. Such is part
of the reason my note is a early warning.

These days the more modern ports lang/gcc* allow use of -stdlib=libc++
as well, allowing the use of the system libc++ library when it is
compatibile. But that gets back into what my notes report.

But, as far as I know, system clang and the various devel/llvm* are
not configured to handle -stdlib=libstdc++ . (Such would have to get
the library from a port or such.)

libstdc++ is GPL3 these days as I understand, which may be a
constraint for some contexts.

> 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.

FreeBSD updating its C++ ABI would be a rather major change,
or so I would expect. Likely avoided as long as possible?

I wonder what property of std::pair's implementation is at
issue for the ABI version distinction(s).

> 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.

At some point lang/gcc* might become an alternative for code
set up to import std or std.compat . But until that happens,
fewer projects are likely to try to use such imports.

===
Mark Millard
marklmi at yahoo.com