[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] tools/ocaml: Fix library generation
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-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |