Hi! On Wed, 2016-10-26 at 05:08:52 +0200, Guillem Jover wrote: > On Wed, 2016-09-07 at 00:48:17 +0200, Bálint Réczey wrote: > > 2016-09-04 3:03 GMT+02:00 Balint Reczey <bal...@balintreczey.hu>: > > > Many packages fail to build due to gcc ... -shared -no-pie ... failing. > > > I have reported the issue to GCC but they don't seem to fix that: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 > > > > > > The proposed workarounds don't seem to be viable in Debian thus I > > > propose making the -pie dpkg hardening flag a noop instead of passing > > > -no-pie and friends as compiler/ flags like in the proposed patch. > > > This is not symmetric but consistent with Ubuntu's way of enabling PIE. > > Wow, that sucks, and we circle back at the situation of enabling PIE by > default and shared libraries failing, but in the inverse. :) > > > I'm rebuilding all packages failed with the original patch and a good share > > does compile with the following additional patches. > > > > I would have preferred only the original patch, but apparently this is > > our best chance for enabling PIE for the archive. > > I think this is very unfortunate, and would make disabling PIE a PITA, > which I'd rather not inflict onto maintainers. > > > I'll start filing bugs for for the packages still failing to build. > > If it's to start adding -pie then sure, otherwise I'd ask if you could > hold off, as I've started to combine the patch in > <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/builtin-pie-bindnow> > with > <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/dpkg-buildflags-pie-gcc-specs> > to use the specs file trick but to disable instead of enable the > option, which should in principle work. It's really late here, and I'm > going to sleep, but I'd appreciate some testing once I've got it ready > tomorrow or so.
Ok, I ended up finishing this up now, but I've not tested the results, the commit is: <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/builtin-pie-bindnow&id=2facf7bb7f148672282e01ea86b4c10dff4d0ef2> Thanks, Guillem
