From nobody Tue Jul 30 05:14:55 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WY3MN05QBz5RDW6 for ; Tue, 30 Jul 2024 05:15:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WY3MM4DFVz4nSN for ; Tue, 30 Jul 2024 05:15:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722316509; bh=y4H24XACsjg1xCVMniuXl3MHUC8+oH98FzI8lOTM6OA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=LvydplI2sCM+rFMeON/Um28JpSplqEP8QYNn1VxOLDGETm/MjdI+HW2uedaLv7GrUVsVYTk93kDrHH0q3EpTBlqsxLqRIAj/Mon+pj9ECgZ97RYFaZ4IGxMWHdEIQ0y9PXxT1+EzVA+sPs0RtZoiRhnZEmlUbVic5X31097Z9yb7PGHRlO59gaVTw+MAHWP9yKoXn7TrjicJaK8U0jgrmUSOxfgbvoH0X6etR/Yb0n0KXaqHOjBtTG+1hWFWZnvqKrKoxuo3kcxKlZaTvA0Klzamb4ewy8Bq8p4GM27NTbkoZe73ZK47mAn6+cpvkib4TCd5XBX8lHTrwTAfO7T23w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722316509; bh=B0eCtimtqxzlGOZ69tNMCU6YFSSDaueUeZcbR0Xorda=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=IviNOJ4fR0pyS/lCIZF/smrfSLipkLpbGRSRnxH9hRNl/CuKSNr85uZwA+nkrBpiQoXgtjMLBQcFd/ufgUMoYNpYJmrW83Qe5+kByOsBM0OWwUjWklvVyvaHCW6EKJpAJb5l9Df15JpF3MWXu0SH7e4t6rdLCLOPqHrVBhXaaiFjiB1TXnX9i5Y44A4KZGZ+Q78L3TsmcmvhaaYkGT+Pr3pB5CVBEGUz98WdzBYF+kRulTpauS6Y8FUAvGnP8tGuCClkDLy9HVAJt3IxaDqNj6ozayw1j9NN2uIkTdNJjA9uLTXF39vEjoyfNNbTILrsDPL0svSaxjUSCZNtpXDgAA== X-YMail-OSG: HoJ5Zk0VM1mlwcAjFeWd.FFDKIqxGPg_dNuNsnyTU53oVaNaRrJGJpxaOm193Ua Z4sDYDEZHsTW8AVbEsckXWy1Bed.46K9FTC790tE_zfQsWC2vbm8CwB4mLwYJrMwI01sNE3d5DeY qj7LhAm0czZEaP5QAcjAKWQ.u5lM7pMB_AwqZmhN9nQEzzpn1CWKMI7oOZNyAM1OwClG8x8JY1wu XhnjitPJO5_gLbclUtJ5ThQNpqmUVbYtj_UPDPfxiWgN.Le8QrGiB1wWvSj_InOP0Tlsoq0oniOs ujHXP_Vip8B8UettHq5qr5.dsAE5f5jOVvmhUZs0LoHUpiaN73uNfSdhnMN.acr.i201znZcBGfG iVP2AslAg1vglhrnTbzLgAWK.WxaJmSZhpHeqrgfvm41ynzYJ7GbSxL.FNDJA1FrLXSySKy0L4I3 WcFNz3WWq291YnOrJsvzWsMTmEGIutO9NhRrDADiB7a8RHIao7qz71p61D.y0FzS8.ZCV2TVciF. RYZ8btWvZFF3fo1C.fg7_F8a5GKBgDfDMoC2xNg.1EtRPz5Ce.AhYYpCt5t.UUNBFQq3A0c2OeO8 a5yLMyKIpW6_K6qLoYnlFVP1qMzU9xqMVGsNl7UOb9g3UDc0G02UrIPr7c3sVkquvONiVdD7sEii au_fSbeEhihIlNORGO58y8XNHmSo86Yjh7fk3h6N__yfKILk7RbaQ_NblIUBsFUPA7G.Cc3dTsVy hc6XU5DMSSjrEOrbZzBfSpcddJT1ghgIGeGKtXdq66mNKrUfubK0toWrpWzp_J5W5_a.MSycXshC R07q4pD8k_WLcmPDyrvMCNWGReQQDeBmZLACAXhgGxYg0yr3KWpfstyi0EpW2S5MiZE.NEhX4b5r pts0Ym3WdQBTTUSq4b3UaLFp.BBCQaadVZHVWyOFn9LeaI74qRYheUdzynZe2Jpqec8XuAVowWvv IcofUgaiVIblz_yDCy_TKw4WYymX0lJ5fRmA8Omp33duj18kM1TW8O90ZvgPIQw6iiDjIdVsb.nH Myb1bz7HBTlIHbfRibDPzpHijNZH55hAqisGTZuG6nUx.OxUFWjqXYedjPOnbW7xGP_dIwR0O7Le BEQx5pML63LatfRtW_7A061X6oyerIfdjG16KiYfJzS3rk1fA0qVHt3MKjQDhaqWXIIp7kNei3p7 .z11gBhF867rxRAjhZaM6GTgFlAMSue9S4gB8QpaPec2qTMeK37Vkd.8oX9tgJLuiy_jsKdAHRnA XP.ySdxsLVMFnzNX_CYqCiIFpfg0oAmWzYQktaoRXhXPgqyq.s0PNafXcl_OMvcvK9pD3wfchV_S sOESf6qVfgV2HvMqlZIvHexRvnOrJZxI9wsEtIW8IBuhC43RQPK7SmX9M56XiWP0d5HjnbTdMiNc HXggjLU.r8kwtaRImUwdLGB01yea09pKnVrge19tH7fiD_WPj1D0IvIWQtZWOqsM6w.GurdptCAS _IOaGYw2yqwc14iV926zu86FMXoKpZy78ehNWhzaNoJHgBumhr_MIJIXu3266.iQ6DI9NZ2sIYxJ p4uY4mZnr7YlSXkP5Qc6hgL3asqoOqiGnr4hraeTJ16IRLUr3SS_AryHL0Jzosyf8srfNRpqJNsR LuilkSEzp6RgPzrxX.XkPFzDGmt375SmmGP0z.YKJLknmlGD.UYZiffWazu7HjeDy50WoKmyK8HM gZ03HjUAKpFu56hMEN.uaDOY5DQbtmcWCwXWBcSjfYJ0yoNbPF_rch41E7F17jjVPTMfeE0r6xZP v4MQXISPMDIYfRvLEiv73Kaz4A_Qpws3hUtoEz1j7sI.FelFQlgs62Lb8ieSCRa.glq74q9oHJCl ezFjtCpYWQGO.MSjfDmXEOW0IR7AKsRyLLUqAANLMsB8KwSu8uRxLMYNJFv_9d27r1gNRAOnlwiq NaWv1pRd5YO3vu9QtiDC9pTKFaHCTExZYjSQ9boJ26UKyVJo24ge03XotH80oDC6RnveC7iAz7UN V6YBhqKPugNIZfmcoZ5PSIVqNtHykZ0VW5.iTXvH467_gl77wl7JYD15FBqY00fSdt3LErLfIaHR d1o3NjrHtZnhksfIuH0LWavJq.fMG7djCN9ZBUpR2yyqa0zVpuhGQCCVn1kUKVYzg2YYsKcp9e2O gwZS2cq.tRwNZeIQnr9MwOdjm7jtGhdvjt7q18YF2Erhu2Xz89E.v9s.gb4mpsk7vx1HZj95dakV Lhy2EFQw.9zKbVc_l2V3hJ6othe6q3M1e70Wo1lZoP6Kmt8hupYs9yHKgQvpMXRYJZxYEHRVh7wy ijP.2a6QEOqf9RHFoxA-- X-Sonic-MF: X-Sonic-ID: e61a8420-bf75-4819-bd7b-60e6aaabbe88 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Jul 2024 05:15:09 +0000 Received: by hermes--production-gq1-799bb7c8cf-cvhk6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d2cae25f9c3d7c1c003d12974b7a5cec; Tue, 30 Jul 2024 05:15:06 +0000 (UTC) From: Mark Millard Message-Id: <98D4961E-2BEF-465E-8ACE-99587A089951@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5" List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? Date: Mon, 29 Jul 2024 22:14:55 -0700 In-Reply-To: <03578B4A-BA6A-4F9D-BCE0-9C01A84623C5@FreeBSD.org> Cc: Charlie Li , freebsd-arch , FreeBSD Toolchain To: Dimitry Andric References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> <22A8133D-B6E6-4818-932A-5D6B03882AC4@yahoo.com> <03578B4A-BA6A-4F9D-BCE0-9C01A84623C5@FreeBSD.org> X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WY3MM4DFVz4nSN --Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 29, 2024, at 09:18, Dimitry Andric wrote: > On 29 Jul 2024, at 18:01, Mark Millard wrote: >>=20 >> On Jul 29, 2024, at 07:54, Charlie Li wrote: >>> ... >=20 >>> 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. >>=20 >> FreeBSD updating its C++ ABI would be a rather major change, >> or so I would expect. Likely avoided as long as possible? >>=20 >> I wonder what property of std::pair's implementation is at >> issue for the ABI version distinction(s). >=20 > 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 =3D=3D 1 . . . # if defined(__FreeBSD__) # define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR # endif and ( __utility/pair.h ): template 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 =3D=3D 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. >=20 > 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 =3D=3D 1 without = _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR defined ) have the _LIBCPP_ABI_VERSION =3D=3D 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 =3D=3D 2 at = all for the issue at hand. (Yes, this would mean going forward that for N>=3D 1, libc++.so.(N+1) = would be for _LIBCPP_ABI_VERSION =3D=3D 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. >=20 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 ? =3D=3D=3D Mark Millard marklmi at yahoo.com --Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 =3D=3D 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 =3D=3D 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 =3D=3D = 1 without _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR d= efined

) have the  _LIBCPP_ABI_VERSION =3D=3D 1 with _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR d= efined 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 =3D=3D 2 at all for the issue at = hand.

(Yes, this would mean going forward that = for N>=3D 1, libc++.so.(N+1) would be for _LIBCPP_ABI_VERSION =3D=3D 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 ?


=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5--