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? > 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.) > 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. > Implementing this approach is a minimal change to the infrastructure, > and it only pulls in a gcc dependency when there's a real benefit. > It's opaque to end-users; doesn't change the bootstrap process or > require editing mk.conf afterward. Except, as someone pointed out offlist, we neeed to protect building gcc* from being affected by this variable. > Based on what I've seen, I think either of these solutions will work > well and create very few problems, though. The only down side I'm > seeing to the mk.conf solution is some heavy dependencies like perl > being built with the old compiler, and the need for end users to make > manual changes after bootstrapping. Both of these are solvable, > though. At this point the competing school of thought is that bootstrapping aside, the only reasonable appproach is to have a fixed version, and fail if that is not sufficient. And, to match somehow the base compiler. <
Attachment:
signature.asc
Description: PGP signature