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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-04-15 at 13:19 +0100, Andrew Cooper wrote:

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

This matches my understanding.

One thing which isn't clear to me is if the command line options which
are embedded are also used as part of building the module itself or if
they are only used when the module is linked against.

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

Right, and in this latter case when linking against the ocaml module we
needs to be sure we are picking up a version of the library which is
consistent with what the module was built against (including headers
etc). i.e. we need the right ABI.

This means that -lfoo and /path/to/libfoo.so are both equally wrong, it
needs to be the thing which libfoo.so links to, or the intermediate
"MAJOR" version SONAME variant iff that declares sufficient ABI
compatibility. e.g.

libxenctrl.so -> libxenctrl.so.4.2
libxenctrl.so.4.2 -> libxenctrl.so.4.2.0
libxenctrl.so.4.2.0

So specifying libxenctrl.so is wrong (as is -lxenctrl, which is
~equivalent). Either or libxenctrl.so.4.2 or libxenctrl.so.4.2.0 would
be OK. A C application ends up with a NEEDED value of libxenctrl.so.4.2
so that's probably the one to use here too.

How do the dllFOO_stubs.so libraries:
        $ find tools/ocaml/ -name dll\*stub\*so
        tools/ocaml/libs/xb/dllxenbus_stubs.so
        tools/ocaml/libs/eventchn/dllxeneventchn_stubs.so
        tools/ocaml/libs/xl/dllxenlight_stubs.so
        tools/ocaml/libs/xc/dllxenctrl_stubs.so
        tools/ocaml/libs/mmap/dllxenmmap_stubs.so
        tools/ocaml/xenstored/dllsyslog_stubs.so
fit in? They do not appear to have a suitable ELF NEEDED entry for the
library which they are stubbing for -- could that be the actual root
cause of this issue? I'm not entirely sure how those are built or used
but given that dllxenctrl_stubs.so uses symbols from libxenctrl.so I'd
have said it ought to have a NEEDED libxenctrl.so.4.2 in it.

However I'm not sure how these stub libraries get used, oxenstored
appears to dynamically link against libxenctrls.so.4.2 and not the
dllxenctrl_stubs.so -- so I guess it gets embedded at link time? So I'm
not at all sure if a NEEDED header in dllxentrl_stubs.so would get
propagated to the final application binary (arguably it should).

Ian.


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