Re: [Xen-API] [Xen-devel] [PATCH v2] tools/ocaml: Fix library generation

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-04-15 at 11:27 +0100, Andrew Cooper wrote:
> On 15/04/13 11:21, Ian Campbell wrote:
> > On Mon, 2013-04-15 at 11:09 +0100, Vincent Bernardoff wrote:
> >> Fix the commands given to the OCaml compiler to make the OCaml
> >> bindings to Xen usable outside the build environment.
> >>
> >> Signed-off-by: Vincent Bernardoff <vincent.bernardoff@xxxxxxxxxx>
> >>
> >> ---
> >> Changed since v1:
> >>    * tools/Rules.mk is not modified, changes are now in
> >>           bottom-level Makefiles of OCaml libraries
> > How does this relate to the patch which Andy Cooper posted in
> > <fe2d14f39de68ab01ac2.1365012176@xxxxxxxxxxxxxxxxxxxxxxxxxxx> ?
> 
> As stated somewhere on one of the two threads, this patch from Vincent
> supersedes mine.

Ah, I'd missed one of the threads (despite replying to it at one point!)

> >
> >> diff --git a/tools/ocaml/libs/eventchn/Makefile 
> >> b/tools/ocaml/libs/eventchn/Makefile
> >> index 2d8d618..ddd2ace 100644
> >> --- a/tools/ocaml/libs/eventchn/Makefile
> >> +++ b/tools/ocaml/libs/eventchn/Makefile
> >> @@ -8,7 +8,7 @@ OBJS = xeneventchn
> >>  INTF = $(foreach obj, $(OBJS),$(obj).cmi)
> >>  LIBS = xeneventchn.cma xeneventchn.cmxa
> >>  
> >> -LIBS_xeneventchn = $(LDLIBS_libxenctrl)
> >> +LIBS_xeneventchn = -L$(XEN_LIBXC) -lxenctrl
> > The problem with this is that it seems to reintroduce a form of the
> > problem solved by b7ee8d2f432f, that is accidental linking against
> > libraries in /usr/lib (or elsewhere) instead of the freshly built ones
> > in the source tree.
> >
> > Andy's version of the patch seems to have solved that issue, I was just
> > hoping for a brief explanation of how (per
> > <1365607338.27868.87.camel@xxxxxxxxxxxxxxxxxxxxxx>) before I through it
> > in the tree.
> >
> > Ian.
> >
> 
> "My patch" was simply an upstreaming of JonL's patch to make XCP build
> against Debian.  I have no particular knowledge of the Ocaml build
> gubbins.  It unfortunatly did not fix the problem in general.

Adding some CCs, please can we try and retain these for any subsequent
threads/postings of this patch.

So what is the correct fix? How bad are the shortcomings of your
proposed fix?

What we need to avoid is either linking a new set of bindings against
stale libraries present on the system outside of the build directory or
the bindings subsequently linking against libraries other than the ones
they were built/linked against. Doing either is likely to result in
crashes for the user.

This suggests that whatever is baked into the ocaml module needs to
include at least a sufficient portion of the SONAME to ensure that the
library which gets used is actually compatible with the one the bindings
were build against. This requires that we don't embed "-lfoo" into the
module since that translates to libfoo.so not libfoo.so.VERSION (or
whichever scheme is used).

If it isn't possible to separate out the command for linking the module
from the one for using it then some hacks might be needed.

Ian.


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api