Re: pkgsrc frozen for 2017Q2

[Greg Troxel <gdt%lexort.com@localhost>]

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.