Re: Why lang/gcc14-devel builds are failing on the build servers: needs USES= compiler:c++14-lang (or higher) instead of compiler:c++11-lang

On 2/8/24 10:11, Mark Millard wrote:
> 
> 
> On Feb 7, 2024, at 23:40, Nuno Teixeira <eduardo@freebsd.org> wrote:
> 
>> USES compiler is somehow deprecated as clang and gcc on base and ports supports capable compiler described in handbook:
>> https://docs.freebsd.org/en/books/porters-handbook/book/#uses-compiler
> 
> Use of the likes of
> 
> USES=           compiler:c++11-lang . . .
> 
> also causes the compile commands to start with:
> 
> c++ -std=c++11  . . .
> 
> ( as shows up in the log file for building lang/gcc14-devel ).
> 
> It is not just about which compiler execuable that is selected
> by the  notation, it is also about telling that executable
> which langauge version it is to apply. libc++ in turn does
> different things for its definitions based on which standard
> is used by the compiler.
> 
> Using the likes of, say:
> 
> USES=           compiler:c++14-lang . . .
> 
> would also cause the compile commands to have:
> 
> c++ -std=c++14  . . .
> 
> that would be provide the constexpr definitions
> needed. Later C++ standards also would provide
> those.
> 
> It is true that the default for -std=c++?? may be
> -std=c++14 or later. But some things fail for use
> of too recent of a standard because of changes in
> the standards as they progress --so the defaults
> need not work. (I've no clue of the specifics for
> building lang/gcc14-devel .)
> 
> I expect that slavadore will pick a notation that
> is sufficient for the builds to work.
> 

   In trying to get up to speed again on how things are done in the 
ports tree, I wish this content was better clairified in the porter's 
handbook. I have been confused by seeing the USES entries with things 
like c++11 then finding the port is building a program the original 
authors set/updated to c++14 through a cmake definition.
   I figure in that case that either it should be left out of the port's 
makefile as the cmake author is maintaining a correct definition or 
should be copied out to the port tree's makefile. Copying seems error 
prone and effort duplication if it wasn't needed to override the 
original and I didn't think this was intended as an override as much as 
to add it if missing.
   Should many of such entries be pruned back out of the ports tree? Is 
there any easy way to determine/warn port authors of redundancy if it is 
not desired?

>> Mark Millard <marklmi@yahoo.com> escreveu (quinta, 8/02/2024 à(s) 05:52):
>> The error on the FreeBSD build servers:
>>
>> QUOTE
>> /wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/config/aarch64/aarch64.cc:13095:50: error: constexpr variable 'tiles' must be initialized by a constant expression
>> 13095 | static constexpr std::pair<unsigned int, char> tiles[] = {
>> | ^ ~
>> 13096 | { 0xff, 'b' },
>> | ~~~~~~~~~~~~~~
>> 13097 | { 0x55, 'h' },
>> | ~~~~~~~~~~~~~~
>> 13098 | { 0x11, 's' },
>> | ~~~~~~~~~~~~~~
>> 13099 | { 0x01, 'd' }
>> | ~~~~~~~~~~~~~
>> 13100 | };
>> | ~
>> /wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/config/aarch64/aarch64.cc:13096:5: note: non-constexpr constructor 'pair<int, char, nullptr>' cannot be used in a constant expression
>> 13096 | { 0xff, 'b' },
>> | ^
>> /usr/include/c++/v1/__utility/pair.h:225:5: note: declared here
>> 225 | pair(_U1&& __u1, _U2&& __u2)
>> END QUOTE
>>
>> is because C++11 did not have pair constructors being constexpr.
>> C++14 (and later) does. Yet lang/gcc14-devel 's Makefile says:
>>
>> USES=           compiler:c++11-lang cpe gmake iconv libtool makeinfo perl5 tar:xz
>>
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
>