On 15.12.2016 13:27, Guillem Jover wrote: > Hi! > > On Wed, 2016-12-14 at 12:54:41 +0100, Matthias Klose wrote: >> Package: dpkg-dev >> Version: 1.18.15 >> Severity: important >> Tags: sid stretch >> >> This is seen on all architectures where pie is not enabled by default. These >> specs should not be passed when pie is not in effect. > > I assume you mean enabled by default by gcc.
No, this particular build log doesn't show any -fPIE/-pie flags, so it is neither enabled by dpkg-buildflags nor by gcc. >> Seen only when looking at the python2.7 ftbfs on x32. And verified that >> the python2.7 build succeeds again when the specs are not passed. > > If python2.7 does not build with the PIE spec files on x32 that means > that either there's a portability issue on x32 in python2.7, or that > there's a more fundamental problem with x32 and PIE (f.ex. openssl1.0 > also only fails on x32 with PIE specs, see #845193, although openssl > builds fine there). > > If the latter, I'd be fine with blacklisting PIE on x32 as "not yet > working", so that it cannot be enabled at all from the dpkg side. > (It also might well be that these packages would fail anyway in case > gcc enabled PIE by default on x32.) Otherwise I guess I'll merge this > and the other report and probably either reassign to gcc or close. > > > The rationale for ending up enabling this globally in dpkg, was that > enabling this partially in gcc means handling this in packaging is an > inconsistent mess. > > We'd have some packages building with PIE in some architectures and > not on others (default hardening build flags option), packages building > with PIE enabled everywhere using gcc default or dpkg PIE enabling specs > (with hardening=+pie), or PIE disabled everywhere using PIE disabling > specs or nothing where gcc does not enable it. > > So we'd need specs files in some places no matter what. And the option > of just never using specs files, and not making it possible to disable > PIE for example or enable it on other arches explicily would be > inconsistent and a pain for maintainers. Well, Balint asked to enable the pie defaults in GCC. I wasn't aware that more work regarding the specs was needed. Ideally these changes should be done in one place, not in two. > We've also never enabled hardening flags partially, all hardening > flags are always enabled as long as they work, otherwise they are just > globally blacklisted on certain arches, even if the packages requests > them. The pie flags are the first ones which have a performance impact, and probably were never tested on our non-linux targets. So yes, I'm careful to apply these on each target. Please live with it that defaults may differ. I don't think that dpkg-buildflags should have any business passing spec files for cases where these spec files are not needed. This is monkey-patching GCC for unrelated or convenience reasons. This did go wrong as seen with #843791, #843826, and now with at least the python2.7 x32 build. For the latter it is not important that the build can/should be fixed or being worked around, but that just passing these specs is causing side effects. The GCC packages don't divert dpkg-buildflags either, and I see this in the end as a diversion as well. And I can't find any docs about what these specs are supposed to do. For the upload of the GCC 6.3.0 release candidate I'm ignoring these spec files when they are not needed. I think this is the least invasive option for the upcoming stretch release. A 'note' message is printed when these options are ignored, so this shouldn't be an issue with any -Werror option either. > I find the current situation pretty suboptimal TBH. :/ Balint and the release team asked to enable this. I raised concerns that this would be too late for the release cycle, but my concerns were ignored (sorry, can't find this email in a bug report, must be on some ML). I'm fine to undo the pie enabling for stretch and work on a better solution for buster if anybody requests this. There are plenty of bug reports where people are not happy with the pie defaults in GCC. Ideally I'd like to see a solution where no spec file changes are required and the the appropriate changes are integrated in GCC upstream. Matthias
