From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Wright Subject: Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC Date: Fri, 01 Aug 2014 12:32:05 +0100 Message-ID: <53DB7AB5.8090805@overnetdata.com> References: <53D6BA4C.7080408@overnetdata.com> <53D75F700200007800027174@mail.emea.novell.com> <53D8024C.3050504@terremark.com> <53D8B4840200007800027838@mail.emea.novell.com> <53D99D82.3090106@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53D99D82.3090106@terremark.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: Don Slutz , Jan Beulich Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 31/07/2014 02:36, Don Slutz wrote: > > 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 The problem was caused by me using the default lzo build options which doesn't build the shared libraries. I rebuilt lzo with the --enabled-shared option, and this fixed the problem in Xen.