On Thu, Apr 17, 2003 at 02:22:22PM +0200, Sven Luther wrote: [...] > > Is this symlink (dll -> lib) a hack or is it the Right Thing? > > It is a hack, i think. > > Basically, the ocaml runtime system will dynamically link files named > dllxxx.so. This was a name scheme chosen with upstream, and we cannot > really change it. > > What Claudio does is that he need to link one of these dllxxx.so > libraries into other dllxxx.so libraries,
Maybe OCaml gurus have an opinion about this issue? > but since gcc expect libraries to be called libxxx.so, Not fully true, here is a test case: $ gcc -shared -fPIC -c -o libxxx.so xxx.c $ gcc -c main.c $ gcc -o withlib -L. -lxxx main.o $ gcc -o withdll libxxx.so main.o $ cmp withdll withlib $ They are strictly identical. In the last case, libxxx.so is not considered as a library (which is why you are not wrong ;)), but as a shared object. And you can then rename it to dllxxx.so. $ gcc -o withdll dllxxx.so main.o Unfortunately ocamlopt does not accept input files with a .so extension, maybe it can be patched to accept them as gcc does? > he uses this symlink hack. And since it is exactly for that that he > needs the rpath, it may well be a good idea that he moves the symlink > to /usr/lib. An alternative is not to link against the other lib, and let developers add all the needed libraries when linking. It is not necessarily a bad thing, you then ensure that there are no linking against conflicting libraries (as with libpng). > A clean way would be to move the common stuff in a true library, which > has a versioned so name, and place this library into /usr/lib, as should > be, and then have wrapper libraries for it. > > The problem is that we plan to have multiple installable versions of > ocaml. ocaml 3.06 installs in /usr/lib/ocaml/3.06/stublibs while ocaml > 3.07 would install in /usr/lib/ocaml/3.07/stublibs. If we have the same > library package for both systems, the either the symlink in /usr/lib, > the common library in /usr/lib or the path in /etc/ld.so.conf would be > conflicting. I guess that ocamlrun will be replaced by ocamlrun-3.06, which will use its own ld.conf to find the right stublibs directory. An analogy with ocamlopt is that the linker should be told to look into /usr/lib/ocaml/x.xx/stublibs and adds an rpath section into the generated binary if stublibs are needed. Just a dumb idea, I have no idea whether this is doable or right. > The real solution for this would be to create a separate package for the > common part, which is not nice, and probably overkill for a common > source code of 50 lines or so. OTOH Remi shows that this was the only problematic example. Denis
