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: Wed, 30 Jul 2014 21:36:02 -0400 Message-ID: <53D99D82.3090106@terremark.com> References: <53D6BA4C.7080408@overnetdata.com> <53D75F700200007800027174@mail.emea.novell.com> <53D8024C.3050504@terremark.com> <53D8B4840200007800027838@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: <53D8B4840200007800027838@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 , Don Slutz Cc: Anthony Wright , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 07/30/14 03:01, Jan Beulich wrote: >>>> On 29.07.14 at 22:21, wrote: >> 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. > Question is - where did you spot us using -fPIE outside any of the > external trees? I didn't find any instance. I did not find any. I also have no issues build with lzo. So I took a guess that this info might help Anthony Wright track down what is wrong. -Don Slutz > Jan >