From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC Date: Tue, 29 Jul 2014 16:21:32 -0400 Message-ID: <53D8024C.3050504@terremark.com> References: <53D6BA4C.7080408@overnetdata.com> <53D75F700200007800027174@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53D75F700200007800027174@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Anthony Wright Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 07/29/14 02:46, Jan Beulich wrote: >>>> On 28.07.14 at 23:02, wrote: >> If xen detects lzo, it tries to build tools/xclib/libxenguest.so.4.4.0 >> with lzo support but fails with the error: >> >> /usr/bin/ld: >> /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/liblzo2.a(lzo_ini >> t.o): >> relocation R_X86_64_PC32 against symbol '_lzo_config_check' can not be >> used when making a shared object; recompile with -fPIC >> >> reading around the subject it would seem to be a problem with the lzo >> library (2.08) which has been built without using the -fPIC option. >> However, when I look at the lzo package there is no standard way to >> build it with -fPIC. My workaround has been simply to remove the lzo >> package, but I'm not sure this is a good solution, and I don't >> understand why this problem doesn't seem to have been encountered before. >> >> Should I be building Xen with LZO support? (does everybody else build >> without LZO support?) >> >> Should I be adding fPIC to the LZO options and rebuilding LZO? >> >> Is there something else I'm doing wrong that is causing the problem? This could also be "broken toolchain" as: Subject: Re: [Xen-devel] [Qemu-devel] [Bug 1257099] [NEW] QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error - msg#00032 On 12/14/13 15:21, Don Slutz wrote: On 12/09/13 08:22, Paolo Bonzini wrote: Il 09/12/2013 13:47, Don Slutz ha scritto: On 12/05/13 22:20, Don Slutz wrote: On 12/05/13 16:24, Richard Henderson wrote: On 12/06/2013 04:18 AM, Paolo Bonzini wrote: $ gcc -shared -o f.so f.c -fPIE -fPIC /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: $ gcc -S -o - f.c -fPIE |grep call call f # PC32 relocation $ gcc -S -o - f.c -fPIC |grep call call f@PLT # PLT32 relocation The easy workaround is to drop -fPIE when we're adding -fPIC. r~ ... talks about. From QEMU configure: # check for broken gcc and libtool in RHEL5 if test -n "$libtool" -a "$pie" != "no" ; then cat > $TMPC < The expectation is that there is a shared library to link against, not > just a static one. If you want the static-only case supported, then > you'll need to contribute patches (and imo those should then cover > not just lzo, but all of the compression methods other than lz4). > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel