Re: ocaml compiled binaries and rpath
On Thu, Apr 17, 2003 at 04:29:15PM +0200, Denis Barbier wrote:
> On Thu, Apr 17, 2003 at 02:22:22PM +0200, Sven Luther wrote:
> [...]
> > > Is this symlink (dll -> lib) a hack or is it the Right Thing?
> >
> > It is a hack, i think.
> >
> > Basically, the ocaml runtime system will dynamically link files named
> > dllxxx.so. This was a name scheme chosen with upstream, and we cannot
> > really change it.
> >
> > What Claudio does is that he need to link one of these dllxxx.so
> > libraries into other dllxxx.so libraries,
>
> Maybe OCaml gurus have an opinion about this issue?
>
> > but since gcc expect libraries to be called libxxx.so,
>
> Not fully true, here is a test case:
> $ gcc -shared -fPIC -c -o libxxx.so xxx.c
> $ gcc -c main.c
> $ gcc -o withlib -L. -lxxx main.o
> $ gcc -o withdll libxxx.so main.o
> $ cmp withdll withlib
> $
> They are strictly identical. In the last case, libxxx.so is not
> considered as a library (which is why you are not wrong ;)), but
> as a shared object. And you can then rename it to dllxxx.so.
> $ gcc -o withdll dllxxx.so main.o
>
> Unfortunately ocamlopt does not accept input files with a .so extension,
> maybe it can be patched to accept them as gcc does?
>
> > he uses this symlink hack. And since it is exactly for that that he
> > needs the rpath, it may well be a good idea that he moves the symlink
> > to /usr/lib.
>
> An alternative is not to link against the other lib, and let developers
> add all the needed libraries when linking. It is not necessarily a bad
> thing, you then ensure that there are no linking against conflicting
> libraries (as with libpng).
Mmm, ocaml binding libraries have the C libraries path or name or
whatever embeded, so this could be extended and the user could not even
notice. Don't know if it is technically feasible though.
> > A clean way would be to move the common stuff in a true library, which
> > has a versioned so name, and place this library into /usr/lib, as should
> > be, and then have wrapper libraries for it.
> >
> > The problem is that we plan to have multiple installable versions of
> > ocaml. ocaml 3.06 installs in /usr/lib/ocaml/3.06/stublibs while ocaml
> > 3.07 would install in /usr/lib/ocaml/3.07/stublibs. If we have the same
> > library package for both systems, the either the symlink in /usr/lib,
> > the common library in /usr/lib or the path in /etc/ld.so.conf would be
> > conflicting.
>
> I guess that ocamlrun will be replaced by ocamlrun-3.06, which will
> use its own ld.conf to find the right stublibs directory. An analogy
Yes.
> with ocamlopt is that the linker should be told to look into
> /usr/lib/ocaml/x.xx/stublibs and adds an rpath section into the
> generated binary if stublibs are needed. Just a dumb idea, I have
> no idea whether this is doable or right.
Mmm, ...
> > The real solution for this would be to create a separate package for the
> > common part, which is not nice, and probably overkill for a common
> > source code of 50 lines or so.
>
> OTOH Remi shows that this was the only problematic example.
For now, but it may change in the future. Their is a legitimate usage,
and not one that can really be done differently. Maybe we need to
discuss this upstream.
Friendly,
Sven Luther
Reply to: