Re: ocaml compiled binaries and rpath
Sven Luther <luther@dpt-info.u-strasbg.fr> writes:
> 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.
dllbigarray.so: no rpath or runpath tag found.
dllcamlzip.so: RPATH=/usr/lib
dllci_freetype.so: RPATH=/usr/local/lib
dllci_gif.so: RPATH=/usr/local/lib
dllci_jpeg.so: RPATH=/usr/local/lib
dllci_png.so: RPATH=/usr/local/lib
dllci_tiff.so: RPATH=/usr/local/lib
dllci_xpm.so: RPATH=/usr/local/lib:/usr/X11R6/lib
dllgraphics.so: RPATH=/usr/X11R6/lib
dlllablglade2.so: no rpath or runpath tag found.
dlllablglade.so: RPATH=/usr/lib:/usr/X11R6/lib
dlllablgl.so: RPATH=/usr/X11R6/lib
dlllablglut_stubs.so: no rpath or runpath tag found.
dlllablgnome.so: RPATH=/usr/lib:/usr/X11R6/lib
dlllablgtk2.so: no rpath or runpath tag found.
dlllablgtkgl2.so: no rpath or runpath tag found.
dlllablgtkgl.so: RPATH=/usr/lib:/usr/X11R6/lib
dlllablgtkmathview.so: RPATH=/usr/lib/ocaml/3.06/stublibs:/usr/lib:/usr/X11R6/lib
dlllablgtk.so: RPATH=/usr/lib:/usr/X11R6/lib
dlllablrsvg.so: no rpath or runpath tag found.
dlllabltk.so: RPATH=/usr/lib:/usr/X11R6/lib
dllmldbm.so: no rpath or runpath tag found.
dllmlgdome2-xslt.so: RPATH=/usr/lib/ocaml/3.06/stublibs
dllmlgdome.so: RPATH=/usr/lib
dllmlgtk.so: RPATH=/usr/lib:/usr/X11R6/lib
dllncurses_stub.so: no rpath or runpath tag found.
dllnums.so: no rpath or runpath tag found.
dllpcre_stubs.so: no rpath or runpath tag found.
dllsdlloaderstub.so: RPATH=/usr/lib
dllsdlmixerstub.so: RPATH=/usr/lib
dllsdlstub.so: RPATH=/usr/lib
dllsdlttfstub.so: RPATH=/usr/lib
dllshell.so: no rpath or runpath tag found.
dllstr.so: no rpath or runpath tag found.
dllthreads.so: no rpath or runpath tag found.
dlltkanim.so: RPATH=/usr/lib:/usr/X11R6/lib
dlltogl.so: RPATH=/usr/X11R6/lib
dllunix.so: no rpath or runpath tag found.
dllwlexing.so: no rpath or runpath tag found.
liblablgtkmathview.so: RPATH=/usr/lib/ocaml/3.06/stublibs:/usr/lib:/usr/X11R6/lib
libmlgdome2-xslt.so: RPATH=/usr/lib/ocaml/3.06/stublibs
libmlgdome.so: RPATH=/usr/lib
>> 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 ?
It is a stublib, so I believe it should stay there
> 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 ?
Don't know. May be.
>
> 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 ?
Well, those common function may be conversion function (that is
function that make a caml value from some C type). I don't see how
those function could be in any other place that stublib.
>
>> 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.
Yes it does
> BTW, in what packages can i find chrpath ?
in the package chrpath.
--
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
Reply to: