David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > On Sat, Dec 30, 2017 at 12:22:58PM -0500, Greg Troxel wrote: > > > On Fri, Dec 29, 2017 at 11:56:21AM -0500, Greg Troxel wrote: > > I have reverted the addition of GCC_REQD to glibmm/buildlink3.mk on > > HEAD. I left the GCC_REQD in Makefile, as it's true, and in line with > > what we do now for other packages. For NetBSD <=7 I think it really > > doesn't matter if glibmm builds or not on head, as nothing that uses it > > will build. > > > > (On the branch, I think the entire set of programs related to glibmm > > will still be troubled on NetBSD 7 and below, but somewhat better off > > with the bl3 hack. We'll see, but I am inclined to just let that be and > > hope for the best.) > > Have we considered just reverting the offending code in glibmm? I generally tend to not want to fight upstream, so I didn't head down that path. If you can figure out what should be changed, with a patch that isn't too scary, and makes it work with 4.8, that seems like a good path. > > I would like to focus on getting compiler selection logic going. > > Comments would be appreciated on how much trouble it will cause to just > > build gcc with all dependencies dynamically exempted from selection > > logic. I am really inclined to go there first, and add static > > exemptions for known packages if needed, and finally to move to > > bootsrapping in a sub-prefix/different-prefix if it's really necessary. > > ... but you need selection logic to pick the compiler to build gcc > with. So far it is "use the base compiler pointed to by PKGSRC_COMPILER" with the implication of "if your system's compiler can't build gcc5, you are out of luck". > The basic problem is that choice of C++ compiler is a nonlocal > decision, and pkgsrc is bad at and has no support for nonlocal > decisions. Furthermore we don't like to turn them into global > decisions because that causes large amounts of overhead for cases > where the nonlocal problem is not relevant. That's all true, except that I think the basic problem is that people are releasing code that requires newish compilers :-) > In this instance, basically the issue is that if you take the subgraph > of the dependency graph generated by discarding edges where the C++ > ABI is irrelevant, each connected component needs to use the same C++ > compiler. We don't have a way to write down this constraint, let alone > solve for it up front (even in a pbulk run), never mind solve for it > on the fly when building one package at a time with no knowledge of > what the user might be intending to build next. I think the last point is the most important one. We don't know what is going to be built next. So we either statically pick something reasonable (today, that's gcc5, as Jason Bacon's data shows us), or we not only have to do this graph computation but also rebuild other packages when we add a new one. That just seems too hard. The alternative is not so bad. The choice is basically: do you want to be able to build things in C++ (or maybe C++11 or higher)? If so, take the pain of building gcc5 and use it for everything. If not, just use the base compiler That's not quite right, but I think it's operationally pretty close. > (This is not the only example of such a problem, either; various > persistent issues with builtin packages, and mixing native vs. pkgsrc > X, have similar roots.) > > If anyone can figure out a way to write down and deal with such > constraints, it'll help a lot of things. I think that would be a great thing in the glorious future, but that we have to proceed with improved compiler version logic without wiating, so that normal programs will actually build on NetBSD 6, and in a few months, will still build on NetBSD 7. My impression is that almost all people with systems with gcc <= 4.8 would rather build a new version than have the current situation of many things not building.
Attachment:
signature.asc
Description: PGP signature