From: Xavier Leroy <xavier.leroy@inria.fr>
Date: Tue, 14 May 2002 10:54:52 +0200

> Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> (a tool that adds/removes lines from this file) and with Vitaly
> Lugovsky's suggestion (multiple configuration files in a directory).

I was always wondering about the need for removing any directory from
ld.conf: it the directory is not there, there will be no problem
anyway...

> The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> by the Unix dynamic loader.  It is intended to list a small number of
> standard directories that contain shared libraries, typically one
> directory for the "system" libraries (i.e. those provided by the OCaml
> core distribution), one for local extensions (e.g. /usr/local/lib),
> and perhaps one or two for especially large packages with many libraries
> (e.g. /usr/X11R6/lib).  
> 
> When you install a package that provides a C shared library, you don't
> install it in a package-dependent directory and add a line to
> /etc/ld.so.conf with this directory; you install in /usr/lib or
> /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> the same scheme for OCaml shared libraries.

It's not because Unix does something wrong that you have to follow it.
In the past I was installing libraries somewhere else (using --prefix
in most packages) and using -rpath. The trouble is that -rpath is
broken on some Unices, so I've reverted to making symbolic links to
/usr/local/lib for the soname. Otherwise it's a pain to manage.

Now I don't think that the current scheme in caml is perfect, but to
me it works ok. When I delete a library I just delete its directory,
and I'm sure it's clean.

> (And, yes, I haven't followed this recommendation in some of the
> standard OCaml libraries (labltk) or some of my own extensions,
> but I've realized my error and intend to fix this in release 3.05.)

I'm the culprit. And well, I have no definite opinion about libraries in
the standard distribution, just that they set an example.
Note that moving dlls around _is_ dangerous, because you may
end-up with dlls with the same name in different place when
overwriting an existing installation.

By the way, if you're so fond of the C way, using versioning on dlls
would be very useful about this kind of problems (with the version in
the .cma, rather than using symbolic links!)

Cheers,

        Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners