tech-pkg archive

[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 <> 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
for C++14.
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
   toolchain time

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
   standard (C++14)

   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 c++11 compliant?

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.

Home | Main Index | Thread Index | Old Index