Re: libxl: link error

[Gianni Tedesco <gianni.tedesco@citrix.com>]

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