Re: pkg/51266: devel/gobject-introspection build fails on i386-7.99.32

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

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

From: "John D. Baker" <jdbaker%mylinuxisp.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/51266: devel/gobject-introspection build fails on i386-7.99.32
Date: Tue, 2 Aug 2016 14:59:20 -0500 (CDT)

 On Mon, 1 Aug 2016, John D. Baker wrote:
 
 > After updating the amd64 host's local-disk installation to my local build
 > (non-update, to empty OBJDIR, DESTDIR, etc.,), attempting to rebuild
 > "devel/gobject-instrospection" fails in the same fashion as originally
 > reported.
 > 
 > This would seem to indicate that something has corrupted my source tree
 > in such a way that building succeeds, but the runtime of some library
 > or another is broken.  It seems to affect only i386 and amd64 ports.
 > It does not appear to have affected macppc or sparc (to the extent that
 > anything I build for sparc uses 'gobject-introspection').
 > 
 > I suppose there's nothing for it but to remove my -current source
 > tree and check it out fresh.
 
 I checked out fresh src/xsrc and ran a comprehensive diff between that
 and my nominal -current tree.  There were no differences that could
 affect compilation or the resulting binaries.  What differences there
 were were limited to RCS/CVS ID comment blocks indicating differences
 in the time recorded when a handful of files were last updated.  In
 each case, the revision recorded in the files agreed.
 
 > The amd64 release I install is done on one build host while all the
 > others are built on a different build host.  While I build amd64 on the
 > alternate build host as well, I've never actually installed the resulting
 > sets.  As a confirmation, I'll update to an amd64 release built on the
 > alternate host.
 
 The installation from the alternate host causes the same failure.  A
 build from the fresh checkout produces the same failure.  Installing a
 build from yet another build host which has its own independent -current
 source tree produces the same failure.
 
 There's only a few other possibilities left.  One is that I have for some
 time now always built with "-V MKDEBUG=yes -V MKDEBUG_LIB=yes" while the
 TNF builds do not.
 
 The other is that there is some systemic problem with my build hosts,
 possibly stemming from the host OS (amd64-7.0_STABLE) or a hardware
 fault.
 
 Now, I'll try building from scratch without MKDEBUG*, followed by
 MKDEBUG=yes only and possibly MKDEBUG_LIB=yes only.
 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645