On 07/04/17 19:57, Greg Troxel wrote:
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.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?
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.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.)
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.
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?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.
Cheers,
JB
--
Earth is a beta site.