On Wed, 19 Aug 2015 23:03:10 -0300 Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer <perezme...@gmail.com> wrote: > On Wednesday 19 August 2015 23:31:12 Markus Koschany wrote: [...] > Right, but sadly it's (arguably) not a Qt bug (see below).
I think closing this bug report was a bad choice and I am rather disappointed about this move. Closing valid bug reports is wrong. You could also reassign this bug report to GCC or mark it as wontfix. Since all of your reverse-dependencies are affected, I won't be the only one who stumbles about this new behaviour. Other options are to use the -no-reduce-relocations options again. [...] > > I think Qt's -reduce-relocation option reduces our ability to harden > > our binaries. To workaround this bug I had to change from > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > to > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie > > Actually that should have been -fPIC No, it must be -pie because you must remove the -pie flag in this case. Freeciv builds different game clients for playing the game and one of them is the Qt client. Now I am either forced to build all binaries without -pie or to heavily patch the build system. Of course Freeciv upstream doesn't consider this to be a Freeciv specific bug. > Actually this behavior was introduced by me while uploading 5.4.2 to the > archive. > > The problem is actually that gcc's upstream do not consider the gcc bug you > noted above as a bug. Thus Qt's upstream developer Thiago Macieira had no > option but to require using -fPIC: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886#c30 > > So with my maintainer hat on I consider this not a bug: you need to pass > -fPIC to the applications that build against qt. > > If you really think it should be different then please do as suggested in the > Arch linux's bug report: complain to upstream at > https://bugreports.qt.io/browse/QTBUG-45755 or at their mailing list > developm...@qt-project.org. If you get to convince upstream of this believe > me > we won't have any problems in changing whatever is necessary. My understanding of being a Debian maintainer is that this is actually your job. Why would we need a BTS if every maintainer decided to close bug reports and requested to open them upstream instead? You should have a far better insight into your package than I have and you might be able to convince upstream, if you have worked with them before. Why would they listen to me, if my own distribution maintainer closes the bug report right away? Regards, Markus
signature.asc
Description: OpenPGP digital signature
