Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?
- Reply: Dimitry Andric : "Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?"
- In reply to: Charlie Li : "Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 29 Jul 2024 16:01:46 UTC
On Jul 29, 2024, at 07:54, Charlie Li <vishwin@freebsd.org> 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