On 2/8/24 10:11, Mark Millard wrote:


On Feb 7, 2024, at 23:40, Nuno Teixeira <[email protected]> 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 <[email protected]> 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




Reply via email to