On Wed, 2017-03-08 at 13:26:15 +0100, Thorsten Glaser wrote: > Dixi quod… > > Turns out that this is almost certainly caused by an issue in glib2. > > Indeed, seems as this “just goes away” with newer dpkg, so it was > almost certainly caused by this -specs=/usr/share/dpkg/pie-link.specs > nōnsense, like… a plethora of other things.
Again, as I've mentioned many times now, this is not a problem with the -specs files per-se. They are just fine. The problem here is the same that affects cmake, petsc and probably other packages. The completely broken and dumb gcc patch that was subverting the dpkg build flags, and emitting a gcc note to boot (#854061). <https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-6/debian/patches/ignore-pie-specs-when-not-enabled.diff?revision=9202&view=markup> As already mentioned in: <https://lists.debian.org/debian-devel/2017/01/msg00522.html> Which in this case, makes the GNUC visibility check, which relies on stderr being empty to fail for obvious reasons [0]. So, no the specs files are not broken, what's still broken is gcc, although because dpkg has been offered as sacrifice in this war, now it does not emit these flags, and gcc and its gods do not get upset anymore… [0] configure.ac:660 and acglib.m4:107 > I’ve scheduled binNMUs for some of the affected architectures and > will give-back gimp on them after that’s through, so we’ll see if > that fixes things. I’ve asked Adrian on IRC for binNMUs on the other > architectures I lack porter permissions for. > > If this is successful I’ll close this bug. It's very possible that many other things are broken due to the broken gcc patch, possibly silently, you want want to check the interval from when that was introduced to when dpkg stopped triggering it. But I'd appreciate if you can stop this misdirected crusade against dpkg here and its specs file, which is not the one that introduced the breakage. Thanks, Guillem