xen 4.4.0 dependency lzo fails to build from source due to fPIC

xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Anthony Wright]

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.

Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Jan Beulich]

>>> 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

Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Don Slutz]

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

Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Jan Beulich]

>>> 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

Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Anthony Wright]

----- 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.

Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Don Slutz]

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
>

Re: xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Anthony Wright]

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.