Re: ocaml compiled binaries and rpath
On Wed, Apr 16, 2003 at 12:19:10PM +0200, Remi Vanicat wrote:
> Remi Vanicat <vanicat@labri.u-bordeaux.fr> writes:
>
> > Sven Luther <luther@dpt-info.u-strasbg.fr> writes:
> >
> >> On Wed, Apr 16, 2003 at 12:27:59AM +0200, Denis Barbier wrote:
> >>> This was for the libc migration.
> >>>
> >>> AFAICT OCaml situation is very different:
> >>> * library location is not well established
> >>
> >> Yes and no. We standardized the dll.so location in the stublibs
> >> directory, and most of the time this is enough. Users or rogue packages
> >> can still install stuff all over the place.
> >>
> >> But i have the feeling that that the rpath is not really there to find
> >> the stublibs, which are found by the ocaml ld.conf file, but to find the
> >> C libraries these stublibs wrap, and this is why directories like
> >> /usr/lib and /usr/X11R6/lib are used. And especially you are not
> >> supposed to link a stublib from another.
> >
> > This in not completely true. One could want to write a binding for a
> > gtk widget not in lablgtk, without having to modify lablgtk, while
> > using some of the lablgtk function. Then it could be useful to link
> > the new stublib to the lablgtk one.
>
> 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.
Could you provide a complete list of the files and the corresponding
rpaths ? The /usr/local/lib seems strange, and is maybe hand added by
the build process.
> For example lablgtkmathview 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.
Mmm, after a bit of testing, i see. That said, the libmlgdome.so is a
symlink to the dllmlgdome.so, and maybe it would make more sense to move
this symlink to /usr/lib/libmlgdome.so, would it not ? Or maybe
something else because the libmlgdome.so does not have a propper so name ?
There is a bit of policy and discution about this going on.
notice that :
$ ldd dlllablgtkmathview.so
...
libmlgdome.so => /usr/lib/ocaml/3.06/stublibs/libmlgdome.so (0x4054a000)
So is this mapping the result of the rpath or something else ?
Also, i understand that this is needed because lablgtkmathview reuse
parts of the mlgdome bindings. Would the propper way of doing this not
be to put the common part in a true library under /lib, and have both
the lablgtkmathview and mlgdome stub libs be only stub libs, and not
inter dependent, and use the common library ?
> 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).
Normal, because it is pulled in by the /etc/ld.so.conf mapping. Could
you add /usr/lib/ocaml/3.06/stublibs to your /etc/ld.so.conf, regenerate
the ldconf cache (by running ldconfig as root) and try launching the
program. I suppose it would work.
BTW, in what packages can i find chrpath ?
Friendly,
Sven Luther
Reply to: