Re: git: bc9e19dce0ab - main - Fix buildworld with gcc 12 after llvm-19 import

On 28 Oct 2024, at 20:56, John Baldwin <jhb@freebsd.org> wrote:
> 
> On 10/25/24 12:08, Dimitry Andric wrote:
>> The branch main has been updated by dim:
>> URL: https://cgit.FreeBSD.org/src/commit/?id=bc9e19dce0abee80750e6fa04aaf979873bfe0d2
>> commit bc9e19dce0abee80750e6fa04aaf979873bfe0d2
>> Author:     Dimitry Andric <dim@FreeBSD.org>
>> AuthorDate: 2024-10-25 16:07:59 +0000
>> Commit:     Dimitry Andric <dim@FreeBSD.org>
>> CommitDate: 2024-10-25 16:08:32 +0000
>>     Fix buildworld with gcc 12 after llvm-19 import
>>          Unfortunately gcc 12's is not yet capable of compiling all of libc++
>>     19's C++23 code, which results in errors similar to:
>>            /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:41:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Iter, _Sent, const _Type&, _Proj)' must be a non-static member function
>>          41 |   operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = {}) {
>>             |   ^~~~~~~~
>>       /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:48:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Range&&, const _Type&, _Proj)' must be a non-static member function
>>          48 |   operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) {
>>             |   ^~~~~~~~
>>          Until we can get rid of gcc 12, work around this by making it compile
>>     libc++ in C++20 mode instead.
>>          NOTE: The resulting libc++ library will not be C++23 compatible! Please
>>     try to avoid shipping it, and use gcc 13 instead, if you must use gcc.
>>          PR:             280562
>>     MFC after:      3 days
> 
> In this case I think we probably should drop support for GCC 12 for main.  Just let me
> know when you are thinking of merging libcxx 19 to stable branches so I can ensure they
> build with GCC 13/14 and get our CI jobs updated before then.

It depends a bit on how many ports still need to be fixed, and of course when 13.5 and 14.2 are done. After those I will probably do the merges.

That said, is gcc 13 good for all arches we want to support? In the past we still kept a few old gcc versions alive because they were the only one that could build for $OBSOLETE_ARCH.

-Dimitry