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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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