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