[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Selecting a C++ compiler
On 10/10/17 19:34, Greg Troxel wrote:
Joerg Sonnenberger <joerg%bec.de@localhost> writes:
On Tue, Oct 10, 2017 at 08:48:27PM +0200, Edgar Fuß wrote:
So what about something along the lines of the attached patch?
The idea is to have the user select a GCC version to compile all C++ dialects
with (GCC_CXX_VERSION, default 48) and
-- complain if the selected version doesn't support the used dialects
-- complain if the version mandated by GCC_REQD is higher
-- otherwise use that version instead of _GCC_REQD.
The default should probably be chosen more intelligently and the list of
unsupported dialects is probably incomplete.
The problem here is that "doesn't support the used dialect" is not black
and white. For some C++11 programs, GCC 4.7 is enough, others might need
up to GCC 5.1 (for a compliant STL implementation). Similar situation
I feel like we're getting close to being able to make progress on this.
I think you are saying that 4.7, 4.8, 4.9 do not fully support C++11, in
that there are some conforming programs for which they will fail to
But there are many C++ programs that use some C++11 features and still
work on some of 4.7, 4.8, 4.9. Right now these of course get tagged
So if we say "USE_LANGUAGES+=c++11" on a particular program, we need 5.1
to be safe, but a lower version might well be ok. This is a milder
version of the current problem where we add --std=c++11 to 4.5 and it
I think our choices here come down to:
1) accept this fuzz, and force 5.1 for c++11, making some people build
a compiler that they might not really need to
2) accept this, and if using < 5.1, realize that some programs will fail
3) add some USE_LANGUAGES values for subflavors of c++11, and then
realize that this will only accomplish cleaner explicit failure at
Overall, I lean to
not worrying too much
having per-OS per-version defaults for compiler version to avoid
building one if that's semi-reasonable (NetBSD 7 and 4.8?) and if one
needs to be built picking one that supports the most modern non-exotic
having the logic cause a hard fail for c++11 and < 4.8 (or < 4.9?)
Does this seem like a reasonable thing to do (trying c+11 builds with <
Or to fail hard if c++11 is in USE_LANGUAGES and < 5.1?
Or do you think we need option 3 above?
Or something else?
I guess a related question is: For netbsd-7 with gcc 4.8, should we let
4.8 be used by default, or force 6?
According to GNU, the full c++11 standard is supported by 4.8.1:
I would guess the failures people are seeing with 4.8 and 4.9 are not
due to c++11 features, but something beyond c++11, or gnu extensions.
Or has it been conclusively proven that some of the failing code is
I'd suggest more time for testing with gcc 5 and later before
mainstreaming them. My first attempt to use gcc 5 across all packages
didn't go well. I had a lot of build failures using something close to
the following in mk.conf:
.if empty(PKGPATH:Mlang/gcc5) && \
empty(PKGPATH:Mpkgtools/cwrappers) && \
empty(PKGPATH:Mdevel/nbpatch) && \
empty(PKGPATH:Mpkgtools/digest) && \
empty(PKGPATH:Msysutils/checkperms) && \
empty(PKGPATH:Mlang/perl5) && \
empty(PKGPATH:Mdevel/p5-gettext) && \
empty(PKGPATH:Mconverters/help2man) && \
empty(PKGPATH:Mdevel/autoconf) && \
empty(PKGPATH:Mconverters/p5-Unicode-EastAsianWidth) && \
empty(PKGPATH:Mdevel/libtool-base) && \
empty(PKGPATH:Marchivers/pax) && \
empty(PKGPATH:Mlang/gcc5-libs) && \
empty(PKGPATH:Mdevel/ncurses) && \
empty(PKGPATH:Mmisc/p5-Locale-libintl) && \
empty(PKGPATH:Mtextproc/p5-Text-Unidecode) && \
empty(PKGPATH:Mdevel/gtexinfo) && \
empty(PKGPATH:Mdevel/gettext-tools) && \
empty(PKGPATH:Mdevel/gettext-lib) && \
empty(PKGPATH:Mdevel/gmp) && \
empty(PKGPATH:Mmath/mpfr) && \
empty(PKGPATH:Mmath/cloog) && \
empty(PKGPATH:Mmath/isl) && \
.endif # GCC_REQD
I plan to try this again soon and examine the issues more closely.
Earth is a beta site.
Main Index |
Thread Index |