tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgsrc frozen for 2017Q2



On 07/06/17 11:50, Greg Troxel wrote:
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.

All sounds good, with one correction:

pkgsrc *does* set -std=c++11 for packages with USE_LANGUAGES=c++ if a dependent package contains USE_LANGUAGES=c++11.

This inheritance of compiler flags by dependencies is the behavior I was questioning.

I've not had any issues with PKGSRC_FORTRAN=gfortran on CentOS.

And get ready, soon we'll have to handle flang, too...

Cheers,

    JB

--
Earth is a beta site.



Home | Main Index | Thread Index | Old Index