Re: -fPIE -pie builds fail
Just a reply to myself. If called as --with-com_err="" it links with shared library just fine and -fPIE -pie seems to compile just OK. I am going to test if it runs ok... Ondrej On Tue, Mar 29, 2011 at 09:56, Ondřej Surý wrote: > Hi, > > I am trying to enable hardening-wrapper for cyrus-imapd-2.4 > (http://wiki.debian.org/Hardening) and I had to disable HARDENING_PIE > because the build failed on: > > gcc -L/usr/lib -L/usr/lib -lpthread -o sievec sievec.o libsieve.a > ../lib/libcyrus.a ../lib/libcyrus_min.a libsieve.a -L/usr/lib > -lsasl2 -ldl -lfl -L/usr/lib -ldb-5.1 -lssl -lcrypto -lz > /usr/lib/libcom_err.a > /usr/bin/ld.bfd.real: /usr/lib/libcom_err.a(error_message.o): > relocation R_X86_64_32 against `.rodata.str1.1' can not be used when > making a shared object; recompile with -fPIC > /usr/lib/libcom_err.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > > It looks like the problem is linking to a static libcom_err.a library. > Does anyone remember why you need to link to a static library here? > > I guess you want a static lib from the configure.in comment: > > COM_ERR_LIBS="-lcom_err" # hope it's not shared > > Ondrej > -- > Ondřej Surý > -- Ondřej Surý
Re: -fPIE -pie builds fail
On Tue, 29 Mar 2011 10:42:16 +0200 Ondřej Surý wrote: > Just a reply to myself. If called as --with-com_err="" it links with > shared library just fine and -fPIE -pie seems to compile just OK. I am > going to test if it runs ok... Hmm.. interesting. We run on Squeeze 64 bit on our production machines. Just going to check how we're building... -g -fPIC -W -Wall -fstack-protector-all Yep, but no PIE. And that's probably because of the com_err stuff. I'll try on my local box (Debian testing) and see what shakes out. Yep, same issue. Then this: cc -shared -O2 -g -L/usr/local/lib -fstack-protector IMAP.o -o blib/arch/auto/Cyrus/IMAP/IMAP.so ../../lib/libcyrus.a ../../lib/libcyrus_min.a \ -ldb-4.8 -lsasl2 -lz -lssl -lcrypto \ /usr/bin/ld: ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_PC32 against symbol `imclient_addcallback' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value which looks to me like the -fPIC and friends aren't being passed down to the Perl library generation. I'd love patches to fix this. I really don't know as much as I should about this part of the process. Bron.
Re: -fPIE -pie builds fail
The current packaging code in our git compiles ok: http://git.debian.org/?p=pkg-cyrus-imapd/pkg-cyrus-imapd-2.4.git;a=summary Unless I discover any problem in the package, I am going to include this in the 2.4.6-3 upload. O. On Tue, Mar 29, 2011 at 12:38, Bron Gondwana wrote: > On Tue, 29 Mar 2011 10:42:16 +0200 > Ondřej Surý wrote: > >> Just a reply to myself. If called as --with-com_err="" it links with >> shared library just fine and -fPIE -pie seems to compile just OK. I am >> going to test if it runs ok... > > Hmm.. interesting. We run on Squeeze 64 bit on our production machines. > Just going to check how we're building... > > -g -fPIC -W -Wall -fstack-protector-all > > Yep, but no PIE. And that's probably because of the com_err stuff. > > I'll try on my local box (Debian testing) and see what shakes out. > Yep, same issue. Then this: > > cc -shared -O2 -g -L/usr/local/lib -fstack-protector IMAP.o -o > blib/arch/auto/Cyrus/IMAP/IMAP.so ../../lib/libcyrus.a > ../../lib/libcyrus_min.a \ > -ldb-4.8 -lsasl2 -lz -lssl -lcrypto \ > > /usr/bin/ld: ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_PC32 > against symbol `imclient_addcallback' can not be used when making a shared > object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > > which looks to me like the -fPIC and friends aren't being passed down to > the Perl library generation. > > I'd love patches to fix this. I really don't know as much as I should about > this part of the process. > > Bron. > -- Ondřej Surý
Re: -fPIE -pie builds fail
On Tue, 29 Mar 2011 13:33:15 +0200 Ondřej Surý wrote: > The current packaging code in our git compiles ok: > > http://git.debian.org/?p=pkg-cyrus-imapd/pkg-cyrus-imapd-2.4.git;a=summary > > Unless I discover any problem in the package, I am going to include > this in the 2.4.6-3 upload. Fantastic. I'm having a look at your repository now. I'll be doing an upstream 2.4.7 within the next couple of days. warning: no common commits Are you building from tarballs? Is it worth re-building your git repository on top of the official cmu repository and then re-applying your changes on top... it would make it easier to cherry-pick I imagine. Bron.
Re: -fPIE -pie builds fail
>> The current packaging code in our git compiles ok: >> >> http://git.debian.org/?p=pkg-cyrus-imapd/pkg-cyrus-imapd-2.4.git;a=summary >> >> Unless I discover any problem in the package, I am going to include >> this in the 2.4.6-3 upload. > > Fantastic. I'm having a look at your repository now. > > I'll be doing an upstream 2.4.7 within the next couple of days. > > warning: no common commits > > Are you building from tarballs? Yes. > Is it worth re-building your git > repository on top of the official cmu repository and then re-applying > your changes on top... it would make it easier to cherry-pick I > imagine. Interesting idea, I'll try that. Anyway we keep all patches in debian/patches/ subdirectory, so there's no urging need for that. O. -- Ondřej Surý
Re: -fPIE -pie builds fail
On Tue, 29 Mar 2011 14:43:38 +0200 Ondřej Surý wrote: > > Is it worth re-building your git > > repository on top of the official cmu repository and then re-applying > > your changes on top... it would make it easier to cherry-pick I > > imagine. > > Interesting idea, I'll try that. Anyway we keep all patches in > debian/patches/ subdirectory, so there's no urging need for that. Oh - fair enough then. I used to do patch queues, but I've moved to having a "moving branch" which rebases on top of the current upstream master. In a less bleeding-edge configuration it would rebase on top of the current upstream stable release branch. Bron.
