[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/51266: devel/gobject-introspection build fails on i386-7.99.32
The following reply was made to PR pkg/51266; it has been noted by GNATS.
From: "John D. Baker" <jdbaker%mylinuxisp.com@localhost>
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
> 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
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
Main Index |
Thread Index |