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 09:18, Dimitry Andric <dim@FreeBSD.org> wrote:

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

Looking, I eventually found ( __config ):

#  elif _LIBCPP_ABI_VERSION == 1
. . .
#    if defined(__FreeBSD__)
#      define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR
#    endif

and ( __utility/pair.h ):

template <class _T1, class _T2>
struct _LIBCPP_TEMPLATE_VIS pair
#if defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
    : private __non_trivially_copyable_base<_T1, _T2>
#endif
{
. . .

So this is not a 1 vs. 2 issue:  it is a FreeBSD-specific odd definition of 1 that
does not apply to other contexts with _LIBCPP_ABI_VERSION == 1 . I'd not
noticed that in the prior references that I'd run into. (It fits with your wording
below, sort of "early 1 vs. late 1" to invent terminology.)

> After it was settled in those committees, libc++ changed its implementation to match, but this actually breaks the ABI!

Sort of "FreeBSD early libc++ ABI 1" vs. "normal late libc++ ABI 1" ABIs.

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

If FreeBSD wants an officially stable libc++ without the forced __non_trivially_copyable_base<_T1, _T2> then it could:

) have  libc++.so use .2 for libc++ _LIBCPP_ABI_VERSION == 1 without _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR defined

) have the  _LIBCPP_ABI_VERSION == 1 with _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR defined case for libc++.so.1 put into that 'compat' package for the sake of old binaries

There is no reason to need to deal with _LIBCPP_ABI_VERSION == 2 at all for the issue at hand.

(Yes, this would mean going forward that for N>= 1, libc++.so.(N+1) would be for _LIBCPP_ABI_VERSION == N without the FreeBSD oddity.)

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

How important is having a numerical match for libc++.so.(_LIBCPP_ABI_VERSION)  instead of the +/- 1 shifting between the .so and the _LIBCPP_ABI_VERSION ?


===
Mark Millard
marklmi at yahoo.com