Re: ocaml compiled binaries and rpath
On Wed, Apr 16, 2003 at 12:56:38PM +0200, Remi Vanicat wrote:
> 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.
>
> 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
Do you really have something in /usr/local/lib ? Maybe you are using a
locally installed ci_ library ? ci_ for camlimage ?
> dlllablgtkmathview.so: RPATH=/usr/lib/ocaml/3.06/stublibs:/usr/lib:/usr/X11R6/lib
> dllmlgdome2-xslt.so: RPATH=/usr/lib/ocaml/3.06/stublibs
> liblablgtkmathview.so: RPATH=/usr/lib/ocaml/3.06/stublibs:/usr/lib:/usr/X11R6/lib
> libmlgdome2-xslt.so: RPATH=/usr/lib/ocaml/3.06/stublibs
These are the only interesting ones, and coming from the same upstream.
Claudio i guess.
> >> 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
The stublib, no problem, but what about the lib... symlink ?
> > 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.
Let see what Claudio has to say about this.
> >> 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
Ok, one solution would be to simply add /usr/lib/ocaml/3.06/stublibs to
/etc/ld.so.conf, or perhaps to say that the only authorized rpath in an
ocaml library package is the stublib dir ? This way, there is a good
reason for this, and we can teach lintian to override this.
I still don't like the lib... symlinks though, there has to be an easier
way, but then, maybe we would find the same mess elsewhere, as these
stublibs don't have so numbers, right ?
> > BTW, in what packages can i find chrpath ?
>
> in the package chrpath.
:)))
Friendly,
Sven Luther
Reply to: