Re: [Xen-devel] xen 4.4.0 dependency lzo fails to build from source due to fPIC

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 07/29/14 02:46, Jan Beulich wrote:
> > > > On 28.07.14 at 23:02, <anthony@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel