Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2011-10-18 at 15:11 +0100, Ian Campbell wrote:
> 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.

The rules in tools/ocaml/Makefile.rules use:
         $(foreach lib,$(LIBS_$(1)),-cclib $(lib))
Where -cclib is documented as passing -l<arg> to the linker. Passing "-l
$(XEN_LIBXC)/libxenctrl.so" doesn't seem like it is going to be right.

-ccopt just passes the raw argument in and seems likely to be more
correct (irrespective of any of the changesets mentioned here, since the
variable seems to have always included -L and -l itself). Perhaps that
helps?

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel