tech-pkg archive

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

Re: pkgsrc frozen for 2017Q2



On 07/04/17 19:57, Greg Troxel wrote:
Jason Bacon <bacon4000%gmail.com@localhost> writes:

So far I've built googletest, R, Octave, GCC 4.8, 4.9, and 5 and a few
biology packages, 279 packages in all.

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?
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.
The only issue I've run into with either approach is dependencies
inheriting the -std=c++11 flag where I have

.if !empty(USE_LANGUAGES:Mc++11)
GCC_REQD+=      4.8
.endif

I fixed a few of these by simply adding USE_LANGUAGES=c++11, forcing
them to build with 4.8 as well.
The notion that a package can be less than c++11 and link with C++
libraries that need C++11 does not compute.  I can see this
theoretically if the dependencies use C++11 internally and do not
expose a C API, but that's not how it is.

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.

That said, since we end up pulling in a GCC package for *some* C++ packages in any case, we might as well use it for all of them and get ABI compatibility, better optimizations, etc.

I think making c++ in general imply GCC_REQD is an elegant solution as
it causes all C++ code to be built with the same compiler (unless
there's an explicit override in the package).  C-only packages can
still be built with any compiler (which should not cause any major
issues), and Fortran is handled separately by already-existing
controls.  I always use PKGSRC_FORTRAN=gfortran, so mine should end up
using the same GCC package as C++ by default.
Not quite; it may use a less aggressive version.
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?

Cheers,

    JB

--
Earth is a beta site.



Home | Main Index | Thread Index | Old Index