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=/<>=.
-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
signature.asc
Description: This is a digitally signed message part.
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
