Re: ocaml compiled binaries and rpath
On Wed, Apr 16, 2003 at 12:42:47PM +0200, Claudio Sacerdoti Coen wrote:
> Somebody wrote:
>
> > > I've just look to the rpath one can found into the dll of
> > > /usr/lib/ocaml/3.06/stublibs :
> > > the directories are : /usr/lib /usr/local/lib /usr/X11R6/lib
> > > /usr/lib/ocaml/3.06/stublibs. The first 3 are not useful (I think),
> > > but the last one seem to be needed.
> > > For example lablgtkmathview
>
> Here we are. This is the problematic package that inspired my elaborated
> example, which was just a stream-lined version of the lablgtkmathview
> dependencies.
Actual examples are always easier to follow than artificial created
ones.
> > > have a rpath to
> > > /usr/lib/ocaml/3.06/stublibs, and if one remove the rpath using
> > > chrpath, then it won't work anymore (the toplevel won't load it,
> > > because it won't find libmlgdome.so). I've just make the test.
>
> Exactly.
>
> > > But for example libmlgdome.so have a rpath only to /usr/lib and seem
> > > to still work after I've remove it. (I've done a lot of test, but it
> > > is still loaded by the toplevel).
>
> Exactly again: libmlgdome does not depend on other bindings.
> lablgtkmathview does.
Ok, i think i now fully understand what is going on here.
> The point is that stublibs is added to ocaml/ld.conf, that is used
> only by the ocaml libraries and not by the bindings ===> we need
> the -rpath for bindings depending on bindings.
It is one solution, but they are others, as i said in my response to
Remi. Too bad the debian lists have such a lag.
> If you find a -rpath free solution for lablgtkmathview, I would be
> very very interested in studing it!
1) move the lib... symlink to /usr/lib or another such ld.so friendly
directory. => Problem could come from so versions and multiple
versions of the library packages. There is standard C policy about
this, and we could alsways use alternatives if need be.
2) add the stublibs to ld.so.conf. May cause problems when more than
one ocaml version is installed at the same time, not a problem today,
but may be problematic in the future.
3) separate the common stuff into its own library and put this one
into /usr/lib, same problem as in 1).
There may be more solutions, but i can't think of them right now.
Friendly,
Sven Luther
Reply to: