On 2017-07-06 1035 , Jason Bacon wrote:
On 07/04/17 19:57, Greg Troxel wrote:
Jason Bacon <bacon4000%gmail.com@localhost> writes:
At least within the GCC 4.x family, making c++11 imply GCC_REQD
doesn't seem to cause any ABI issues. I'm curious as to why the
-std=c++11 flag is passed down to dependencies, though. Was this even
intentional?
This is a key question. If a package needs C++11 and hence the newish
runtime, then how is it reasonable for an older compiler and especially
runtime to be used to build a depending package?
At some point (not this week, and not by me) pkgsrc was changed to insert
--std for C++ sublanguage higher than base. This seems right to me;
an upstream
C++ package should be written for a specific sub-language and should
document
that in the README. As I understand it, different compilers have
different defaults
for --std, generally age-correlated. I recently ran into an upstream
that didn't set
--std, and the package failed to build on netbsd-7 with gcc 4.8. Once
I changed
USE_LANGUAGES from c++ to c++11, which upstream did document, then it
worked.
So clearly 4.8 was defaulting to something earlier than c++11, which
makes sense, because
4.8 seems to be one of the earlier versions that supports c++11.
Arguably such an upstream should test for and add the --std flags
itself, e.g. via
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html
My actual concern here is inserting a compiler flag (-std=c++11) that
the upstream developers did not intend to use. The c++11 standard
deprecates a number of language features, so this might cause some
compile issues with older code. I didn't see this in the ~300
packages I built, to it's probably not going to be a big issue. I
also haven't maintained my C++ skills in recent years, so I don't
know if any of the deprecated features would trigger errors vs.
warnings.
But they did, or should have, intended to choose a language variant.
If you don't set the flag, the std you get depends on the compiler
version.
Setting the flag explicitly reduces surprises.
If an upstream both uses withdrawn features and new features, it needs
fixing.
I don't think you are saying this, but pkgsrc does not set --std=c++11
for packages
that have USE_LANGUAGES=c++, and despite talk of "same compiler for
all c++', I
did not mean to imply "same --std flags".
But, I am not aware of any real breakage from this, beyond the usual
upstream-needs-patching
kind of thing.
After a while, following another suggestion, I changed this to:
.if !empty(USE_LANGUAGES:Mc++)
GCC_REQD+= 4.8
.endif
There have been no build failures since.
So your evidence is that the mixed compiler usage resulting from only
forcing 4.8 for C++11 results in issues, but forcing 4.8 for any C++ is
ok. (Taking liberties, but trying to summarize fairly.)
Sort of. But it could be argued that the issues were caused by
pkgsrc inserting a -std=c++11 flag without forcing a compatible
compiler to be used.
It only inserts --std=c++11 when the package is declared to use c++11.
A compiler that doesn't support c++11 should error out cleanly if
passed --std=c++11. gcc 4.1 errors for c++0x and c++11, and 4.5 for
c++11.
My understanding is that USE_LANGUAGES=fortran will use whichever gcc
package is currently installed. Is that correct? I realize, though,
that if we build a package requiring Fortran before any C++ packages
are built (seems unlikely, but possible), we could end up with two
different gcc dependencies. Should the minimum GCC version also be
applied to Fortran packages to avoid this?
In general, I'd like to see behavior that does not change based on
what's already installed.
I know we default apache to 22 vs 24 based on an install, and that
isn't bothersome, but
changing compilers leads to nonrepeatable builds.
Dealing with Fortran is a whole separate can of worms. As I
understand it, people who
set PKGSRC_FORTRAN=gfortran are not reporting a lot of trouble.
There's another point of view about the whole issue, which is that
(with gcc family) mixing
runtimes from versions leads to ABI incompataibilty, and that's
unsound, so we should
just force the version for the entire pkgsrc build (default,
user-overridable).
This would turn GCC_REQD into "fail build if gcc and gcc < foo".
If we end up there, gfortran can certainly come along for the ride.