* xen 4.4.0 dependency lzo fails to build from source due to fPIC @ 2014-07-28 21:02 Anthony Wright 2014-07-29 6:46 ` Jan Beulich 0 siblings, 1 reply; 7+ messages in thread From: Anthony Wright @ 2014-07-28 21:02 UTC (permalink / raw) To: xen-devel@lists.xen.org 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_init.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? Any suggestions appreciated. Anthony. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC 2014-07-28 21:02 xen 4.4.0 dependency lzo fails to build from source due to fPIC Anthony Wright @ 2014-07-29 6:46 ` Jan Beulich 2014-07-29 20:21 ` Don Slutz 2014-07-30 9:03 ` Anthony Wright 0 siblings, 2 replies; 7+ messages in thread From: Jan Beulich @ 2014-07-29 6:46 UTC (permalink / raw) To: Anthony Wright; +Cc: xen-devel@lists.xen.org >>> On 28.07.14 at 23:02, <anthony@overnetdata.com> 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? 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC 2014-07-29 6:46 ` Jan Beulich @ 2014-07-29 20:21 ` Don Slutz 2014-07-30 7:01 ` Jan Beulich 2014-07-30 9:03 ` Anthony Wright 1 sibling, 1 reply; 7+ messages in thread From: Don Slutz @ 2014-07-29 20:21 UTC (permalink / raw) To: Jan Beulich, Anthony Wright; +Cc: xen-devel@lists.xen.org On 07/29/14 02:46, Jan Beulich wrote: >>>> On 28.07.14 at 23:02, <anthony@overnetdata.com> 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 <<EOF void *f(unsigned char *buf, int len); void *g(unsigned char *buf, int len); void * f(unsigned char *buf, int len) { return (void*)0L; } void * g(unsigned char *buf, int len) { return f(buf, len); } EOF if ! libtool_prog; then echo "Disabling libtool due to broken toolchain support" libtool= fi fi -Don Slutz > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC 2014-07-29 20:21 ` Don Slutz @ 2014-07-30 7:01 ` Jan Beulich 2014-07-31 1:36 ` Don Slutz 0 siblings, 1 reply; 7+ messages in thread From: Jan Beulich @ 2014-07-30 7:01 UTC (permalink / raw) To: Don Slutz; +Cc: Anthony Wright, xen-devel@lists.xen.org >>> On 29.07.14 at 22:21, <dslutz@verizon.com> wrote: > On 07/29/14 02:46, Jan Beulich wrote: >>>>> On 28.07.14 at 23:02, <anthony@overnetdata.com> 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. Jan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC 2014-07-30 7:01 ` Jan Beulich @ 2014-07-31 1:36 ` Don Slutz 2014-08-01 11:32 ` Anthony Wright 0 siblings, 1 reply; 7+ messages in thread From: Don Slutz @ 2014-07-31 1:36 UTC (permalink / raw) To: Jan Beulich, Don Slutz; +Cc: Anthony Wright, xen-devel@lists.xen.org On 07/30/14 03:01, Jan Beulich wrote: >>>> On 29.07.14 at 22:21, <dslutz@verizon.com> wrote: >> On 07/29/14 02:46, Jan Beulich wrote: >>>>>> On 28.07.14 at 23:02, <anthony@overnetdata.com> 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC 2014-07-31 1:36 ` Don Slutz @ 2014-08-01 11:32 ` Anthony Wright 0 siblings, 0 replies; 7+ messages in thread From: Anthony Wright @ 2014-08-01 11:32 UTC (permalink / raw) To: Don Slutz, Jan Beulich; +Cc: xen-devel@lists.xen.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, <dslutz@verizon.com> wrote: >>> On 07/29/14 02:46, Jan Beulich wrote: >>>>>>> On 28.07.14 at 23:02, <anthony@overnetdata.com> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC 2014-07-29 6:46 ` Jan Beulich 2014-07-29 20:21 ` Don Slutz @ 2014-07-30 9:03 ` Anthony Wright 1 sibling, 0 replies; 7+ messages in thread From: Anthony Wright @ 2014-07-30 9:03 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel ----- Original Message ----- > >>> On 28.07.14 at 23:02, <anthony@overnetdata.com> 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? > > 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 Thanks, I rebuilt the lzo2 library with the --enable-shared option, and it successfully built. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-08-01 11:32 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-28 21:02 xen 4.4.0 dependency lzo fails to build from source due to fPIC Anthony Wright 2014-07-29 6:46 ` Jan Beulich 2014-07-29 20:21 ` Don Slutz 2014-07-30 7:01 ` Jan Beulich 2014-07-31 1:36 ` Don Slutz 2014-08-01 11:32 ` Anthony Wright 2014-07-30 9:03 ` Anthony Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).