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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 -fPICI 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel