Re: glibmm build issues with gcc 4.8

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

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:
 > >> As a hacky approach, I not only put GCC_REQD+=4.9 in glibmm's Makefile
 > >> but also the bl3, to force packages that link against it to 4.9.  I
 > >> realize this is unsound, as it doesn't force packages that link against
 > >> those to use 4.9.  But, with this, gnome-system-monitor builds, which
 > >> means atkmm, pangomm, and gtkmm also build.
 > >
 > > As I said before, please don't do that. It makes the situation even
 > > worse.
 > 
 > 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 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.

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.

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.

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

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