On Thu, 2016-12-15 at 23:26:11 +0100, Matthias Klose wrote: > On 15.12.2016 13:27, Guillem Jover wrote: > > 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.
I only understood this request after reading the gcc patch. So, you meant not enabled explicitly by the package or by the builder. > > 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. At this point I think it was a mistake to enable this in GCC, given the current situation… > 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. They are needed whenever PIE needs to be enabled or disabled, and gcc does not do that already. > This did go wrong as seen with #843791, #843826, These were just bugs, in the same way #849542 was an implementation bug. > 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. gcc in the end does what the upper layers tell it to do, and in the end the distribution policy is set by the specific packages or by dpkg-buildflags if the packages decide to use it. By that measure all packages are diverting gcc whenever they diverge from gcc defaults… > And I can't find any docs about what these specs are supposed to do. I'm not sure what kind of documentation you are looking for. > 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. Oh, wow, I saw that, and lost all motivation to discuss this any further. But there's too much fallout due to this, so it needs to be addressed one way or another. That patch is just broken-by-design. It is a complete layer violation. It also breaks unrelated software such as cmake (#851720) due to that 'note'. And breaks any package that does not export DEB_BUILD_MAINT_OPTIONS from debian/rules, such as any using the dpkg architecture.mk fragment or when calling dpkg-buildflags with the --export=configure or --export=cmdline options, or similar constructs. I'll start a thread on d-d, as switching to the behavior that you request, which I consider pretty suboptimal, impacts porters and package maintainers. If there's consensus to do the switch then I'll do that. > > 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. Well, at this point I'd rather remove all traces of PIE support from dpkg-buildflags and let you and Bálint handle all this mess, unfortunately this is not possible, as one of the *the* interface to enable this in packages is precisely dpkg-buildflags… Regards, Guillem
