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 
In file included from 
                 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: 
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.

How do I need to change the CPP/C++/CFLAGS, so we get what we want? Or is this 
a bug from Qt side?



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

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply via email to