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

On 29 Jul 2024, at 18:01, Mark Millard <marklmi@yahoo.com> wrote:
> 
> On Jul 29, 2024, at 07:54, Charlie Li <vishwin@freebsd.org> wrote:
>> ...

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

It's a bit of a historical wart that is hard to get rid of. In FreeBSD we were "too early" and changed our standard C++ library to libc++ before this std::pair trivial copy constructor issue was hashed out in the standards committees. After it was settled in those committees, libc++ changed its implementation to match, but this actually breaks the ABI! For anybody who switched to libc++ after that time, there was no problem using the new ABI, but in FreeBSD we have been stuck with the older interpretation ever since.

Changing the ABI involves bumping libc++.so to .2, and putting libc++.so.1 into a 'compat' package for the sake of old binaries. I had originally wanted to do this for FreeBSD 14 but never got to it, and for some reason upstream is also stalled for years now in bumping their own official ABI version to 2.

It would be preferable if upstream libc++ bumps its 'stable' ABI to 2 and starts working on 3 as the then-experimental one, then all downstream consumers can upgrade, leaving all compat crutches behind.

-Dimitry