CVS commit: src/tools/gcc

[matthew green]

Module Name: src
Committed By: gutteridge
Date: Sun Jun 16 16:03:30 UTC 2024
src/tools/gcc: Makefile
tools/gcc/Makefile: force std=c++11 for GCC 12 builds
GCC >= 11 now requires C++11 to build. Impacted individual components
vary whether they test for if std=c++11 is the default or has to be
passed. Regardless, our build infrastructure applies its own overrides.
Force this setting so that we can still build on NetBSD 8.x hosts (and
probably 7.x, too). Build tested on NetBSD 8.3.

i'm not sure i like this. the build environment is expected to
provide a valid compiler, and the above assumes how the compiler
works.

if we really want to support this without user-env setup, then
i think a confiure test (from tools/compat) would be better than
forcing this option here directly.

(also note this is not the first time this sort of issue has
arrived, and we always asked the build-env provider to fix it,
but i'm not against eg, the configure test idea.)

thanks.


.mrg.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David H. Gutteridge]

Post by matthew green

Module Name: src
Committed By: gutteridge
Date: Sun Jun 16 16:03:30 UTC 2024
src/tools/gcc: Makefile
tools/gcc/Makefile: force std=c++11 for GCC 12 builds
GCC >= 11 now requires C++11 to build. Impacted individual components
vary whether they test for if std=c++11 is the default or has to be
passed. Regardless, our build infrastructure applies its own
overrides.
Force this setting so that we can still build on NetBSD 8.x hosts (and
probably 7.x, too). Build tested on NetBSD 8.3.

i'm not sure i like this. the build environment is expected to
provide a valid compiler, and the above assumes how the compiler
works.
if we really want to support this without user-env setup, then
i think a confiure test (from tools/compat) would be better than
forcing this option here directly.
(also note this is not the first time this sort of issue has
arrived, and we always asked the build-env provider to fix it,
but i'm not against eg, the configure test idea.)

I can certainly simply revert for now, if you prefer.

I'm a little confused by your answer, as there are pre-existing bits
that already do this or something similar. (Well, or intend to.)

tools/isl/Makefile has:

# XXX this gets lost some how. Not portable.
HOST_CXXFLAGS+= -std=gnu++17

A different example is from tools/Makefile.gmakehost:

# Disable use of pre-compiled headers on Darwin.
BUILD_OSTYPE!= uname -s
HOST_COMPILER_CLANG!= if ${HOST_CC} --version | grep -q -s clang; then
echo yes; else echo no; fi
.if ${HOST_COMPILER_CLANG} == "yes"
HOST_CFLAGS+=-O2 -no-cpp-precomp
.endif

The latter is intended to deal with a different sort of issue, but I
see it as being related in terms of reaching over and injecting its
own HOST_* values. If we say "the host should sort out its own issues",
effectively, then I don't see why that would be there, either. (There
is more like that elsewhere.)

I realize I supplied a "GCC-style" argument that not all compilers
will accept. I don't know what compilers would be viable now other than
GCC and Clang?

The goal is to be able to set different compiler flags on a per
component basis. There could be other components that don't want the
same standard forced (or whatever). To your point, we could have
something that tests and sets a make variable that's conditionally
applied down in a particular component.

Regards,

Dave

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Taylor R Campbell]

Date: Mon, 17 Jun 2024 03:01:55 +1000

Module Name: src
Committed By: gutteridge
Date: Sun Jun 16 16:03:30 UTC 2024
tools/gcc/Makefile: force std=c++11 for GCC 12 builds
GCC >= 11 now requires C++11 to build. Impacted individual components
vary whether they test for if std=c++11 is the default or has to be
passed. Regardless, our build infrastructure applies its own overrides.
Force this setting so that we can still build on NetBSD 8.x hosts (and
probably 7.x, too). Build tested on NetBSD 8.3.

i'm not sure i like this. the build environment is expected to
provide a valid compiler, and the above assumes how the compiler
works.
if we really want to support this without user-env setup, then
i think a confiure test (from tools/compat) would be better than
forcing this option here directly.
(also note this is not the first time this sort of issue has
arrived, and we always asked the build-env provider to fix it,
but i'm not against eg, the configure test idea.)

How is the host C++ compiler supposed to know that we are asking it to
compile C++11 and not C++98 or C++17?

gcc's configure scripts search for a way to pass this information to
the host compiler (e.g., AX_CXX_COMPILE_STDCXX). I'm fuzzy on how
these are supposed to work but it looks like maybe the existing
configure tests are not getting used for some reason.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Taylor R Campbell
How is the host C++ compiler supposed to know that we are asking it to
compile C++11 and not C++98 or C++17?

The compilation line should pass --std=c++11. Arguably, any program
that invokes a compiler and does not pass a --std is buggy. Things only
mostly work because mostly --std=c++17 will compile C++11 programs, and
the tendency is for later compiler versions to have higher default
languages.

In pkgsrc, we have a way to add --std=foo via the wrappers, to handle
packages that don't do this right (generally, at all).

Is that what you meant, or something else?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de