Re: pkg/51266: Seg Faults building devel/gobject-inspection with latest 8.0_BETA

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/51266; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/51266: Seg Faults building devel/gobject-inspection with latest 8.0_BETA
Date: Sun, 25 Jun 2017 10:47:39 +0700

 I have no specific knowledge about what is happening in this PR, and
 I don't think I ever build any of the packages in question, so I cannot
 provide any additional real information, but I keep seeing references to
 it (describe something as "mysterious" and it tends to catch my interest.)
 
 It seem likely to me that while the updated gcc is involved somehow in
 this, most likely only in that it compiles some broken code in a way that
 whoever write it never thought could happen (newer, smarter, versions of
 the compiler tend to do that.)
 
 One piece of information which is most likely useful, and which is lacking
 from all reports here, is what packages are installed at the time a package
 build fails.
 
 pkgsrc & buildlink attempt to hide what is currently installed from a build
 of a package (so only the explicit dependencies are seen) and is quite
 successful in hiding stuff from the compiler, and linker, and even autoconf.
 But when a package build runs arbitrary binaries it compiles along the
 way there's no way buildlink (alone) can hide what is installed - especially as
 packages need to be told where their data, config, etc will be installed,
 and can use that to deduce where other packages will have their data installed
 as well, and so determine whether something which is not a listed depencency
 exists, and if so, use it.
 
 The bulk builds (I believe) hide this from package builds by building
 everything in a chroot, which makes it much much harder to see what is
 in the system.  Are those of you who are having failures using pbulk,
 or pkg_comp, or some other similar method to build in a chroot?
 
 This is the kind of data you ought be collecting - my guess of what is
 happening is that there is some broken piece of code, that newer gcc
 compiles differently than older, actually causing the bad code to have
 bad effects, whereas before it worked by accident.   Then that code is
 being used somehow, as part of the build of other packages, and then
 they end up failing, or perhaps causing others to fail.
 
 Find the common element, just what it is that is the trigger for all of
 this, and you will be a lot closer to actually solving this problem.
 
 kre