On Wed, Apr 16, 2003 at 12:19:10PM +0200, Remi Vanicat wrote: > Remi Vanicat <[EMAIL PROTECTED]> writes: > > > Sven Luther <[EMAIL PROTECTED]> 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
