On Thu, Apr 17, 2003 at 04:29:15PM +0200, Denis Barbier wrote: > 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).
Mmm, ocaml binding libraries have the C libraries path or name or whatever embeded, so this could be extended and the user could not even notice. Don't know if it is technically feasible though. > > 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 Yes. > 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. Mmm, ... > > 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. For now, but it may change in the future. Their is a legitimate usage, and not one that can really be done differently. Maybe we need to discuss this upstream. Friendly, Sven Luther
