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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/04/13 12:04, Ian Campbell wrote:
> 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?

The shortcomings of the patch sent by me is that it completely breaks
the bytecode libraries.  As XCP was only needing to get the native
compile working, that's all that got accounted for.

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

To the best of my understanding:

Ocaml .cma/.cmxa libraries can ether be loaded at runtime, or
subsequently linked against later to create complete programs.

To facilitate that, gcc command line options are embedded in the
cma/cmxa so the correct .so's can be found.

The problem we have is that oxenstored is complied and linked completely
to an executable in the build system, which means it needs the build
system .so locations, while at the same time, the cma/cmxa's need to
have the runtime system library locations so they can be included/linked
against later.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel