libxl: link error

libxl: link error

[Christoph Egger]

Hi!

I get this link error when linking libxl:

ld: libxl_dom.o: relocation R_X86_64_PC32 against symbol 
`hvm_build_set_params' can not be used when making a shared object; recompile 
with -fPIC

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: libxl: link error

[Ian Jackson]

Christoph Egger writes ("[Xen-devel] libxl: link error"):
> I get this link error when linking libxl:
> 
> ld: libxl_dom.o: relocation R_X86_64_PC32 against symbol 
> `hvm_build_set_params' can not be used when making a shared object; recompile 
> with -fPIC

I think this is probably a side effect of the addition of the
"_hidden" attribute (aka `__attribute__((visibility("hidden")))',
defined in libxl_internal.h) to this function ?

Can you explain what the notable differences are between the Linux and
BSD ELF linkers ?  Perhaps the BSD linker does not support this
attribute, in which case we should probably #ifdef it out.

Or perhaps the problem is something else.

Ian.

Re: libxl: link error

[Christoph Egger]

On Friday 13 August 2010 14:29:07 Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] libxl: link error"):
> > I get this link error when linking libxl:
> >
> > ld: libxl_dom.o: relocation R_X86_64_PC32 against symbol
> > `hvm_build_set_params' can not be used when making a shared object;
> > recompile with -fPIC
>
> I think this is probably a side effect of the addition of the
> "_hidden" attribute (aka `__attribute__((visibility("hidden")))',
> defined in libxl_internal.h) to this function ?

This is not the problem but this triggers the issue.

> Can you explain what the notable differences are between the Linux and
> BSD ELF linkers ?  Perhaps the BSD linker does not support this
> attribute, in which case we should probably #ifdef it out.

NetBSD uses the GNU ld. I don't know the differences
in the linker scripts between Linux and NetBSD.

> Or perhaps the problem is something else.

Yes, it is a bug in libxl/Makefile related to my local blktap/noblktap change.
I added the .c instead the .o file. Fixed in my local tree. Sorry for the 
noise.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: libxl: link error

[Christoph Egger]

On Friday 13 August 2010 15:37:08 Christoph Egger wrote:
> On Friday 13 August 2010 14:29:07 Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] libxl: link error"):
> > > I get this link error when linking libxl:
> > >
> > > ld: libxl_dom.o: relocation R_X86_64_PC32 against symbol
> > > `hvm_build_set_params' can not be used when making a shared object;
> > > recompile with -fPIC
> >
> > I think this is probably a side effect of the addition of the
> > "_hidden" attribute (aka `__attribute__((visibility("hidden")))',
> > defined in libxl_internal.h) to this function ?
>
> This is not the problem but this triggers the issue.
>
> > Can you explain what the notable differences are between the Linux and
> > BSD ELF linkers ?  Perhaps the BSD linker does not support this
> > attribute, in which case we should probably #ifdef it out.
>
> NetBSD uses the GNU ld. I don't know the differences
> in the linker scripts between Linux and NetBSD.
>
> > Or perhaps the problem is something else.
>
> Yes, it is a bug in libxl/Makefile related to my local blktap/noblktap
> change. I added the .c instead the .o file. Fixed in my local tree. Sorry
> for the noise.

Argh, I was too fast with sending this mail.

I had commented out the gcc visiblity macros in libxl_internal.h to
see if the problem goes away. Yes, it did and forgot to undo it when
I found and fixed this Makefile problem.

It is definitely something else. The tools/libxl/Makefile specifies -fPIC.
Maybe libxc must be compiled with -fPIC, too?

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: libxl: link error

[Ian Jackson]

Christoph Egger writes ("Re: [Xen-devel] libxl: link error"):
> It is definitely something else. The tools/libxl/Makefile specifies -fPIC.
> Maybe libxc must be compiled with -fPIC, too?

We don't appear to have SHLIB_CFLAGS.  I think that's where -fPIC
should go, and it should be used everwhere where we link the objects
with SHLIB_LDFLAGS.

If we do that then the .o files in the .a's will be -fPIC too but
that's a price worth paying.

I guess this might be fallout from Olaf's LDFLAGS/LIBS patch.

Ian.

Re: libxl: link error

[Olaf Hering]

On Fri, Aug 13, Ian Jackson wrote:

> If we do that then the .o files in the .a's will be -fPIC too but
> that's a price worth paying.

Even .a objects can endup in other .so files, although its unlikely for
the xen case. Better compile shared libs with -fPIC.

> I guess this might be fallout from Olaf's LDFLAGS/LIBS patch.

Sorry if thats the case, perhaps I should have paid also attention to
the -fPIC usage.

Olaf

Re: libxl: link error

[Ian Jackson]

Olaf Hering writes ("Re: [Xen-devel] libxl: link error"):
> On Fri, Aug 13, Ian Jackson wrote:
> > If we do that then the .o files in the .a's will be -fPIC too but
> > that's a price worth paying.
> 
> Even .a objects can endup in other .so files, although its unlikely for
> the xen case. Better compile shared libs with -fPIC.

True.

> > I guess this might be fallout from Olaf's LDFLAGS/LIBS patch.
> 
> Sorry if thats the case, perhaps I should have paid also attention to
> the -fPIC usage.

NP.  This is what we have -unstable for.

Ian.

Re: libxl: link error

[Gianni Tedesco]

On Fri, 2010-08-13 at 13:29 +0100, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] libxl: link error"):
> > I get this link error when linking libxl:
> > 
> > ld: libxl_dom.o: relocation R_X86_64_PC32 against symbol 
> > `hvm_build_set_params' can not be used when making a shared object; recompile 
> > with -fPIC
> 
> I think this is probably a side effect of the addition of the
> "_hidden" attribute (aka `__attribute__((visibility("hidden")))',
> defined in libxl_internal.h) to this function ?
> 
> Can you explain what the notable differences are between the Linux and
> BSD ELF linkers ?  Perhaps the BSD linker does not support this
> attribute, in which case we should probably #ifdef it out.

I realise this thread is about another issue but just FYI:

The hidden attribute is handled by gcc in all architectures (AFAIK)
since it's a detail that's implemented at link (ld) time, not in the
dynamic linkers. In the .o files symbols get prepended with ".hidden "
or some such and then when creating an executable or shared object from
them the absolute or relative address is patched directly in to the
machine code and no symbol is emitted. Since we're targeting GNU C and
not something else it should be fine.

There is one "arch" where this attribute won't work and that's windows,
where everything is hidden by default and you need declspec dllexport
for exported functions. When the patches arrive for libxenlight.dll
we'll then need to have _public as well as _hidden attribute macros and
use them for all non-static functions.

Heh :)