WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Tue, 18 Oct 2011 15:15:35 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir \(Xen.org\)" <keir@xxxxxxx>, Jonathan Ludlam <Jonathan.Ludlam@xxxxxxxxxxxxx>
Delivery-date: Tue, 18 Oct 2011 07:16:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1318947065.3385.26.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <CAFLBxZaYwHe9VH4tSHFBt7jy-EzLjuN87kW0FChH0LOy=EvZnw@xxxxxxxxxxxxxx> <1318947065.3385.26.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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