[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, 2011-10-18 at 14:53 +0100, George Dunlap wrote: > When trying to make a XenServer branch with xen-server, I managed to > get Xen to build, but when I tried to use some of the ocaml output, I > got the following errors: > > gcc: > /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so: > No such file or directory > gcc: > /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenguest.so: > No such file or directory > > > It appears that somehow the change made in 23071:a3466b005017 ended up > putting in a hard-link to the exact directory of the library in the > resulting .ml files, which is only used when someone attempts to > actually use those files. The use of "hard-link" here is confusing. You presumably mean it bakes the literal/precise path into the binary. > Since, of course, those exact directories > are gone when the RPM build is over, this doesn't work very well. :-) > > The attached patch reverts the parts of 23071 which pertains to > tools/ocaml/libs/xc, and the resulting *.ml files work properly again. > But I'm not sure what the desired approach is going forward -- I'm > not familiar enough with the ocaml link process to know what a > "proper" fix would be (i.e., one which accomplishes the goal of 23071) > diff -r 4b0907c6a08c tools/ocaml/libs/xc/Makefile > --- a/tools/ocaml/libs/xc/Makefile Tue Oct 11 12:02:58 2011 +0100 > +++ b/tools/ocaml/libs/xc/Makefile Thu Oct 13 17:28:06 2011 +0100 > @@ -9,7 +9,7 @@ OBJS = xenctrl > INTF = xenctrl.cmi > LIBS = xenctrl.cma xenctrl.cmxa > > -LIBS_xenctrl = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) Nowadays this expands to: $(XEN_LIBXC)/libxenctrl.so $(XEN_LIBXC)/libxenguest.so prior to 23921:19d2922bcfb9 it would have been: -L$(XEN_LIBXC) -lxenctrl -L$(XEN_LIBXC) -lxenguest which tree were you working against? Are you sure 23071:a3466b005017 and not 23921:19d2922bcfb9 is to blame? The <23931 version doesn't seem materially different to the <21071 one whereas I can plausibly imagine that 23931 might have made a difference. If this had been using $(SHLIB_foo) I could have imagined ways in which that might go wrong. > +LIBS_xenctrl = -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |