Hey, I now started to build cpp and qt bindings for gpgme but ran into a issue with the hardening flags. The problem is the -fPIE. With this enabled configure stops with: configure:19628: checking whether a simple qt program can be built configure:19639: g++ -o conftest -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_6 4-linux-gnu/qt5 -fpic -fPIE -pie -Wl,-z,relro -Wl,-z,now conftest.cpp -lQt5Core >&5 In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:37:0, from /usr/include/x86_64-linux-gnu/qt5/QtCore/QCoreApplication:1, from conftest.cpp:33: /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1087:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC ( -fPIE is not enough)." # error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\ ^~~~~
full log: http://sandroknauss.de/files/gpgme1.0_1.7.0-2_amd64_with_hardening.build with hardening disabled it builds successfully and also via replacing -fPIE with -fPIC, but than lintian is unhappy about the missing -fPIE for gpgme-tool. http://sandroknauss.de/files/gpgme1.0_1.7.0-2_amd64_without_hardening.build How do I need to change the CPP/C++/CFLAGS, so we get what we want? Or is this a bug from Qt side? Regards, sandro Am Donnerstag, 22. September 2016, 17:44:38 CEST schrieb Daniel Kahn Gillmor: > On Sat 2016-09-10 13:00:26 -0400, Daniel Kahn Gillmor wrote: > > As i understand it from a talk given by Andre Heinecke (GPGME upstream, > > cc'ed here) at OpenPGP.conf, GPGME 1.7.0 is likely to take over as > > upstream from pyme, gpgmepp, and qgpgme. (it will also add a > > common-lisp binding, but that's not in debian at all, so i'll ignore it > > for now). 1.7.0 isn't yet released, but it sounds like the release is > > due fairly soon. > > 1.7.0 was released a couple days ago, and i just uploaded it to debian > unstable, along with a fair bit of debian packaging cleanup. > > The source package i uploaded currently only builds the C library. It > does not build or attempt to ship the python, common-lisp, c++, or qt > bindings yet. > > > I don't think it'd be unreasonable for the debian GnuPG packaging team > > take on these additional binary packages within the gpgme1.0 source > > package, which would mean that the source packages for python-pyme, and > > gpgmepp would probably go away, and the kdepimlibs library would stop > > building libqgpgme1 and libgpgme++2v5. > > I plan to work in experimental for a version that will produce the > python3 bindings -- binary package python3-pyme in particular. I'm not > yet aiming to "hijack" the 2.x bindings with this source package, since > i haven't heard from Arnaud. > > Arnaud, at some point we should let the gpgme1.0 source package take > over the python-pyme binary package, though, since i understand that it > is now python2-compatible upstream. I haven't heard back from you here, > but given that the transition has happened upstream, i hope it will be > OK. Would you like to help out with this? I'd be happy to have your > input and experience on the python bits (and elsewhere if you're > willing). > > If someone wants to collaborate on doing the same kind of work for qt > and c++, i'm happy to coordinate via the pkg-gnupg-maint git repo, > and/or on IRC #debian-gnupg on oftc. > > --dkg
Description: This is a digitally signed message part.