There seem to be library issues compiling on a system with as-needed. This is directly off xen-unstable tip: make[6]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools/flask/libflask'' ../../../tools/cross-install -d -m0755 -p /var/home/xen41/xen-unstable.hg/dist/install/usr/lib64 ../../../tools/cross-install -d -m0755 -p /var/home/xen41/xen-unstable.hg/dist/install/usr/include ../../../tools/cross-install -m0755 -p libflask.so.1.0.0 /var/home/xen41/xen-unstable.hg/dist/install/usr/lib64 ../../../tools/cross-install -m0644 -p libflask.a /var/home/xen41/xen-unstable.hg/dist/install/usr/lib64 ln -sf libflask.so.1.0.0 /var/home/xen41/xen-unstable.hg/dist/install/usr/lib64/libflask.so.1.0 ln -sf libflask.so.1.0 /var/home/xen41/xen-unstable.hg/dist/install/usr/lib64/libflask.so ../../../tools/cross-install -m0644 -p include/libflask.h /var/home/xen41/xen-unstable.hg/dist/install/usr/include/xen/xsm make[5]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools/flask/libflask'' make[4]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools/flask'' make[4]: Entering directory `/var/home/xen41/xen-unstable.hg/tools/flask'' make -C utils install make[5]: Entering directory `/var/home/xen41/xen-unstable.hg/tools/flask/utils'' gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .loadpolicy.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Wall -g -Werror -I../../../tools/libxc -I../../../tools/include -I../../../tools/flask/libflask/include -I. -c -o loadpolicy.o loadpolicy.c gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .flask-loadpolicy.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Wall -g -Werror -I../../../tools/libxc -I../../../tools/include -I../../../tools/flask/libflask/include -I. loadpolicy.o -L../../../tools/libxc -L../../../tools/flask/libflask -L. -lflask -L../../../tools/libxc -lxenctrl -ldl -o flask-loadpolicy ../../../tools/libxc/libxenctrl.so: undefined reference to `dlsym'' ../../../tools/libxc/libxenctrl.so: undefined reference to `dlerror'' ../../../tools/libxc/libxenctrl.so: undefined reference to `dlopen'' ../../../tools/libxc/libxenctrl.so: undefined reference to `dlclose'' collect2: ld returned 1 exit status make[5]: *** [flask-loadpolicy] Error 1 make[5]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools/flask/utils'' make[4]: *** [subdir-install-utils] Error 2 make[4]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools/flask'' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools/flask'' make[2]: *** [subdir-install-flask] Error 2 make[2]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools'' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/var/home/xen41/xen-unstable.hg/tools'' make: *** [install-tools] Error 2 - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2011-01-27 at 23:05 +0000, Nathan March wrote:> There seem to be library issues compiling on a system with as-needed. > This is directly off xen-unstable tip:> `/var/home/xen41/xen-unstable.hg/tools/flask/utils'' > gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD > -MF .loadpolicy.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Wall -g > -Werror -I../../../tools/libxc -I../../../tools/include > -I../../../tools/flask/libflask/include -I. -c -o loadpolicy.o loadpolicy.c > gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD > -MF .flask-loadpolicy.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > -Wall -g -Werror -I../../../tools/libxc -I../../../tools/include > -I../../../tools/flask/libflask/include -I. loadpolicy.o > -L../../../tools/libxc -L../../../tools/flask/libflask -L. -lflask > -L../../../tools/libxc -lxenctrl -ldl -o flask-loadpolicy > ../../../tools/libxc/libxenctrl.so: undefined reference to `dlsym'' > ../../../tools/libxc/libxenctrl.so: undefined reference to `dlerror'' > ../../../tools/libxc/libxenctrl.so: undefined reference to `dlopen'' > ../../../tools/libxc/libxenctrl.so: undefined reference to `dlclose''libxenctrl.so is linked with -ldl (in tools/libxc/Makefile via $(DLOPEN_LIBS) from config/StdGNU.mk) _and_ it is included in the above link line too. Can you confirm further back in your logs that libxenctrl actually linked against -ldl correctly (it does in my build at least)? Also "ldd tools/libxc/libxenctrl.so" should list libdl I think. I''m not sure what else as-needed needs/expects? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/28/2011 12:53 AM, Ian Campbell wrote:> Can you confirm further back in your logs that libxenctrl actually > linked against -ldl correctly (it does in my build at least)? Also "ldd > tools/libxc/libxenctrl.so" should list libdl I think.Does not appear to be: xen5 xen-unstable.hg # ldd tools/libxc/libxenctrl.so linux-vdso.so.1 => (0x00007fff594c1000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff09b7f6000) libc.so.6 => /lib/libc.so.6 (0x00007ff09b49a000) /lib64/ld-linux-x86-64.so.2 (0x00007ff09bc41000) The gcc line: gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .libxenctrl.so.4.0.0.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -I../../xen/common/libelf -Werror -Wmissing-prototypes -I. -I../xenstore -I../include -L. -Wl,-soname -Wl,libxenctrl.so.4.0 -ldl -shared -o libxenctrl.so.4.0.0 xc_core.opic xc_core_x86.opic xc_cpupool.opic xc_domain.opic xc_evtchn.opic xc_gnttab.opic xc_misc.opic xc_acm.opic xc_flask.opic xc_physdev.opic xc_private.opic xc_sedf.opic xc_csched.opic xc_csched2.opic xc_arinc653.opic xc_tbuf.opic xc_pm.opic xc_cpu_hotplug.opic xc_resume.opic xc_tmem.opic xc_mem_event.opic xc_mem_paging.opic xc_mem_access.opic xc_memshr.opic xc_hcall_buf.opic xc_foreign_memory.opic xtl_core.opic xtl_logger_stdio.opic xc_pagetab.opic xc_linux.opic xc_linux_osdep.opic -lpthread Usually when I''ve run into this in the past it''s just been an issue of putting them in the correct order, take a look at "Importance of linking order" here: http://www.gentoo.org/proj/en/qa/asneeded.xml I''ve also attached the full make output from tools/libxc. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2011-01-28 at 19:09 +0000, Nathan March wrote:> Usually when I''ve run into this in the past it''s just been an issue of > putting them in the correct order,Can you try moving the $(DLOPEN_LIBS) in the libxenctrl rule in tools/libxc/Makefile to the end, e.g. before or after the $(PTHREAD_LIBS)? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/28/2011 11:12 AM, Ian Campbell wrote:> Can you try moving the $(DLOPEN_LIBS) in the libxenctrl rule in > tools/libxc/Makefile to the end, e.g. before or after the > $(PTHREAD_LIBS)? > > Ian.Moving it to the end fixed it: - $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(DLOPEN_LIBS) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS) + $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS) $(DLOPEN_LIBS) But I''m still running into issues, this time with libvhd: gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .vhd-util.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -Wno-unused -I../include -D_GNU_SOURCE -fPIC -Wp,-MD,.vhd-util.d -o vhd-util vhd-util.o -Llib -lvhd -luuid lib/libvhd.so: undefined reference to `uuid_generate'' lib/libvhd.so: undefined reference to `uuid_copy'' lib/libvhd.so: undefined reference to `uuid_is_null'' lib/libvhd.so: undefined reference to `uuid_unparse'' lib/libvhd.so: undefined reference to `uuid_clear'' lib/libvhd.so: undefined reference to `uuid_compare'' collect2: ld returned 1 exit status The line that built libvhd.so was: gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .libvhd.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -Wno-unused -I../../include -D_GNU_SOURCE -fPIC -g -Wp,-MD,.libvhd.o.d -c -o libvhd.o libvhd.c - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2011-01-28 at 19:22 +0000, Nathan March wrote:> On 1/28/2011 11:12 AM, Ian Campbell wrote: > > Can you try moving the $(DLOPEN_LIBS) in the libxenctrl rule in > > tools/libxc/Makefile to the end, e.g. before or after the > > $(PTHREAD_LIBS)? > > > > Ian. > > Moving it to the end fixed it: > > - $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) > -Wl,libxenctrl.so.$(MAJOR) $(DLOPEN_LIBS) $(SHLIB_LDFLAGS) -o $@ $^ > $(PTHREAD_LIBS) > + $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) > -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS) > $(DLOPEN_LIBS)Excellent.> But I''m still running into issues,Sure. Please can you accumulate all the necessary fixes for the as-needed stuff and send them out as one patch once it''s all fixed up.> The line that built libvhd.so was: > > gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD > -MF .libvhd.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror > -Wno-unused -I../../include -D_GNU_SOURCE -fPIC -g -Wp,-MD,.libvhd.o.d > -c -o libvhd.o libvhd.cThat''s the command for libvhd.o not libvhd.so. However I would guess that you need to move the $(LIBS) to the end of the libvhd.a rule in tools/blktap2/vhd/lib/Makefile (which also builds libvhd.so, go figure). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/28/2011 11:36 AM, Ian Campbell wrote:> Sure. Please can you accumulate all the necessary fixes for the > as-needed stuff and send them out as one patch once it''s all fixed up.Sure, will do. Couldn''t see an obvious fix for this one: gcc -o xl xl.o xl_cmdimpl.o xl_cmdtable.o libxlutil.so libxenlight.so -L../../tools/libxc -lxenctrl -ldl -L../../tools/libxc -lxenguest -L../../tools/xenstore -lxenstore -L../../tools/blktap2/control -lblktapctl -lutil -luuid libxenlight.so: undefined reference to `xc_dom_mem_init'' libxenlight.so: undefined reference to `xc_cpuid_apply_policy'' libxenlight.so: undefined reference to `xs_daemon_destroy_postfork'' libxenlight.so: undefined reference to `xs_introduce_domain'' *snip* gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .libxenlight.so.1.0.0.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -Wno-format-zero-length -Wmissing-declarations -I. -fPIC -I../../tools/libxc -I../../tools/include -I../../tools/libxc -I../../tools/include -I../../tools/xenstore -I../../tools/include -I../../tools/blktap2/control -I../../tools/blktap2/include -I../../tools/include -Wl,-soname -Wl,libxenlight.so.1.0 -shared -o libxenlight.so.1.0.0 flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o libxl_utils.o osdeps.o libxl_paths.o libxl_bootloader.o libxl_blktap2.o libxl_cpuid.o _libxl_types.o - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2011-01-28 at 21:19 +0000, Nathan March wrote:> > On 1/28/2011 11:36 AM, Ian Campbell wrote: > > Sure. Please can you accumulate all the necessary fixes for the > > as-needed stuff and send them out as one patch once it''s all fixed up. > > Sure, will do. > > Couldn''t see an obvious fix for this one:Can you try adding $(LDLIBS_libxenctrl) and $(LDLIBS_libxenstore) to the end of the link line for libxenlight.so Probably not the cleanest solution but lets start with finding something which works. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/28/2011 1:54 PM, Ian Campbell wrote:> Can you try adding $(LDLIBS_libxenctrl) and $(LDLIBS_libxenstore) to the > end of the link line for libxenlight.soNo luck. That resulted in this: gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .libxenlight.so.1.0.0.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -Wno-format-zero-length -Wmissing-declarations -I. -fPIC -I../../tools/libxc -I../../tools/include -I../../tools/libxc -I../../tools/include -I../../tools/xenstore -I../../tools/include -I../../tools/blktap2/control -I../../tools/blktap2/include -I../../tools/include -L../../tools/libxc -lxenctrl -ldl -L../../tools/libxc -lxenguest -L../../tools/xenstore -lxenstore -L../../tools/blktap2/control -lblktapctl -lutil -luuid -Wl,-soname -Wl,libxenlight.so.1.0 -shared -o libxenlight.so.1.0.0 flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o libxl_utils.o osdeps.o libxl_paths.o libxl_bootloader.o libxl_blktap2.o libxl_cpuid.o _libxl_types.o -L../../tools/libxc -lxenctrl -ldl -L../../tools/xenstore -lxenstore I also tried putting those two vars in at the beginning and just before the -o, but didn''t help. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2011-01-28 at 22:24 +0000, Nathan March wrote:> On 1/28/2011 1:54 PM, Ian Campbell wrote: > > Can you try adding $(LDLIBS_libxenctrl) and $(LDLIBS_libxenstore) to the > > end of the link line for libxenlight.so > > No luck. That resulted in this:[...]> I also tried putting those two vars in at the beginning and just before > the -o, but didn''t help.Hrm. Same missing symbols as before? Taking a step back, since I think this patch is becoming a little bit too much for a 4.1.0-rc3, lets consider how we can disable as-needed for Xen 4.1.0 and revisit the situation for 4.2 (with the possibility of a back port for 4.1.1 as well). I don''t see any as-needed in your link lines so I presume it was enabled as a compile time option in your ld. I just built Xen with the following patch and it didn''t break on a Debian system (i.e. without as-needed enabled by default). Can you try it in your environment? diff -r d2c7cf306687 config/StdGNU.mk --- a/config/StdGNU.mk Sat Jan 29 10:33:04 2011 +0000 +++ b/config/StdGNU.mk Sat Jan 29 10:39:07 2011 +0000 @@ -65,6 +65,8 @@ SONAME_LDFLAG = -soname SONAME_LDFLAG = -soname SHLIB_LDFLAGS = -shared +LDFLAGS += -Wl,--no-as-needed + ifneq ($(debug),y) CFLAGS += -O2 -fomit-frame-pointer else For 4.2 I was hoping to revisit the issue of libraries not being correctly transitively linked (e.g. libxl is supposed to isolate users from the need to know about libxenctrl and libxenstore so applications which use only libxl should not be expected to have to link with -lxenctrl and -lxenstore). I suspect that there will be a lot of overlap with this and supporting --as-needed as the latter is essentially a workaround for the lack of the former. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/29/2011 2:45 AM, Ian Campbell wrote:> I just built Xen with the following patch and it didn''t break on a > Debian system (i.e. without as-needed enabled by default). Can you try > it in your environment?Initially failed with: ld -Wl,--no-as-needed -melf_x86_64 -r -o built_in.o head.o ld: unrecognized option ''-Wl,--no-as-needed'' ld: use the --help option for usage information Adjusted the patch to have a space instead of a comma between params and I get: gcc -D__ASSEMBLY__ -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/var/home/xen41/xen-unstable.hg/xen/include -I/var/home/xen41/xen-unstable.hg/xen/include/asm-x86/mach-generic -I/var/home/xen41/xen-unstable.hg/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -mno-red-zone -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .head.o.d -c head.S -o head.o ld -Wl --no-as-needed -melf_x86_64 -r -o built_in.o head.o ld: unrecognized option ''-Wl'' ld: use the --help option for usage information xen5 xen-unstable.hg # ld -v GNU ld (GNU Binutils) 2.19.1 If I drop the -Wl out, it bails on: gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .xen-tmem-list-parse.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -I ../../tools/python/xen/lowlevel/xc -I ../../tools/libxc -I ../../tools/include --no-as-needed xen-tmem-list-parse.c -o xen-tmem-list-parse cc1: error: unrecognized command line option "-fno-as-needed" the --no-as-needed is valid for ld according to the man, but not for gcc as far as I can see. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2011-01-31 at 18:14 +0000, Nathan March wrote:> > On 1/29/2011 2:45 AM, Ian Campbell wrote: > > I just built Xen with the following patch and it didn''t break on a > > Debian system (i.e. without as-needed enabled by default). Can you try > > it in your environment? > > Initially failed with: > > ld -Wl,--no-as-needed -melf_x86_64 -r -o built_in.o head.o > ld: unrecognized option ''-Wl,--no-as-needed'' > ld: use the --help option for usage informationThe -Wl,<foo> syntax is for gcc and says "pass <foo> to the linker". If you are just calling the linker directly then you just need the <foo> bit (i.e. --as-needed) However I didn''t notice any direct calls to ld when I tested this patch. Oh, I think I see, the LDFLAGS where patched it effects both the hypervisor and the tools builds but I only tested the tools. Can you try the one below instead. Ian. diff -r c83acd6f343e tools/Rules.mk --- a/tools/Rules.mk Mon Jan 31 09:32:25 2011 +0000 +++ b/tools/Rules.mk Mon Jan 31 19:29:10 2011 +0000 @@ -52,7 +52,7 @@ ifneq ($(XEN_OS),NetBSD) # Enable implicit LFS support *and* explicit LFS names. CFLAGS += $(shell getconf LFS_CFLAGS) CFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -LDFLAGS += $(shell getconf LFS_LDFLAGS) +LDFLAGS += $(shell getconf LFS_LDFLAGS) -Wl,--no-as-needed endif # 32-bit x86 does not perform well with -ve segment accesses on Xen. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/31/2011 11:30 AM, Ian Campbell wrote:> Can you try the one below instead.Confirmed, that''s fixed the compile issues. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell writes ("Re: [Xen-devel] Xen 4.1.0 RC2 released,"):> -LDFLAGS += $(shell getconf LFS_LDFLAGS) > +LDFLAGS += $(shell getconf LFS_LDFLAGS) -Wl,--no-as-neededBefore I commit this change, I do wonder whether there are older versions of GNU ld that don''t support --as-needed and therefore break with --no-as-needed. Does anyone have an ancient build environment they could try this patch on ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2011-02-01 at 18:51 +0000, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] Xen 4.1.0 RC2 released,"): > > -LDFLAGS += $(shell getconf LFS_LDFLAGS) > > +LDFLAGS += $(shell getconf LFS_LDFLAGS) -Wl,--no-as-needed > > Before I commit this change,You don''t want this one, it broke the hypervisor build. There is a post of a fixed patch in a new thread " tools: disable linker --as-needed option" from this morning.> I do wonder whether there are older > versions of GNU ld that don''t support --as-needed and therefore break > with --no-as-needed. > > Does anyone have an ancient build environment they could try this > patch on ?The above thread has some analysis -- I think we''re ok on this score, even Debian Sarge had a new enough ld. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Nathan, On Sat, 2011-01-29 at 10:45 +0000, Ian Campbell wrote:> Taking a step back, since I think this patch is becoming a little bit > too much for a 4.1.0-rc3, lets consider how we can disable as-needed > for > Xen 4.1.0 and revisit the situation for 4.2 (with the possibility of a > back port for 4.1.1 as well).As of commit 23056:1c1ecbcf4100 the tools build in xen-unstable.hg is compatible with --as-needed, as far as I can tell at least. If you are able to build-test the development tree on your system that would be handy. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I can confirm that the 4.1.0 release builds properly here, haven''t got it working yet but I think that''s unrelated. - Nathan On 3/21/2011 7:43 AM, Ian Campbell wrote:> Hi Nathan, > > On Sat, 2011-01-29 at 10:45 +0000, Ian Campbell wrote: >> Taking a step back, since I think this patch is becoming a little bit >> too much for a 4.1.0-rc3, lets consider how we can disable as-needed >> for >> Xen 4.1.0 and revisit the situation for 4.2 (with the possibility of a >> back port for 4.1.1 as well). > As of commit 23056:1c1ecbcf4100 the tools build in xen-unstable.hg is > compatible with --as-needed, as far as I can tell at least. If you are > able to build-test the development tree on your system that would be > handy. > > Thanks, > Ian. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2011-04-01 at 18:38 +0100, Nathan March wrote:> I can confirm that the 4.1.0 release builds properly here,Thanks, but I was asking if you could try building xen-unstable.hg since I think I''ve properly fixed --as-needed support there. In the 4.1.0 tree we simply forced it off as a workaround. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel