Re: glibmm build issues with gcc 4.8

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Mon, Jan 01, 2018 at 10:38:16AM -0500, Greg Troxel wrote:
 > > 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.

The immediate build failure is something about the regexps in the C++
standard library. I have no idea myself what the issue is or even how
to go about figuring out what the issue is, but others may.

(and even if patched, it might not be the only problem)

 > > ... 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".

That most likely unsupports all the junkyard platforms; then again,
most of those probably can't run a modern C++ compiler anyway and
shouldn't try. So they should just default to not building a compiler
from pkgsrc.

But it seems like there should be some support for bootstrapping in
this situation...

 > > 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.

There's another issue: you still have to recompile everything when you
change the compiler you built from pkgsrc.

But even then since there are basically only two choices when you go
to compile something (build the recommended compiler from pkgsrc, or
don't), and since once you've built a compiler from pkgsrc there's no
substantive downside to using it for everything, we can do the
following:

 - when you go to build a package, check the compiler versions of
everything it depends on. (That is, check the actual packages, not the
bl3 files, by repeated or recursive pkg_info invocations.)
 - if these aren't all the same and/or don't match the currently
selected compiler, fail and print the list of packages that need to be
rebuilt.

Doing this in addition to the proposed scheme for deciding what the
currently selected compiler is will add a layer of safety.

It also allows manually building specific packages with the system
compiler if desired with confidence that one won't get screwed later.

And it's making me think there should be a master USE_BUILTIN_GCC
switch (or something like that) so you can do "make USE_BUILTIN_GCC=yes".

(And it would be nice to unify this logic with builtin package
handling, but that isn't going to happen anytime soon.)

I do need to think some about how to structure this so the same or
similar logic will also work for the related issues with x11-links,
though.

 > 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.

How hard is it currently to do that explicitly? I've never tried...

-- 
David A. Holland
dholland%netbsd.org@localhost