Re: [Caml-list] OCaml packaging problems

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Michal Moskal <malekith@pld-linux.org>
> On Tue, May 14, 2002 at 08:39:54PM +0900, Jacques Garrigue wrote:
> > > 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.
> 
> Unix gets it right. That's what package managers are for. You do
> rpm -e foobar (or equivalent) and that's all.

Sure, since this is the Unix way :-)
Package manager are strange beasts, in my opinion overstressed by the
fact they have to install files all over the place.
If Unix had really got it right, there would be no need for file
tracking in package managers, only dependency tracking.
Also, there are plenty of them, and not every ocaml library come with
what is needed to work with a some specific package manager. Most
actually work with none.

> Looking in multiple directories takes time. Think how much would it
> take to check hundred of directories, which is no more then avarage
> linux installation have C libraries. Similar can be told about /usr/bin
> and <tab> in shell.

Not really: ldconfig is caching the contents of directories in
ld.so.conf anyway, so that having lots of directory incurs only a mild
cost at system startup (and reconfiguration).

Anyway, when I said that Unix was wrong, I was not talking of
performance but of functionality. I'm not sure that having a very
long list of directories in ld.so.conf is a good solution,
just that having to put all shared libraries in the same directory is
a pain, and that something should be done about it.  After various
attempts, Unix seems to have dropped the issue (tampering directly
with ld.so.conf on a running system being a bit dangerous for the
faint of heart, LD_LIBRARY_PATH is kind of a hack)

I have no miracle solution, but the current one seemed to be ok.
If we revert to a solution based on a specific directory for dlls
(preferably not lib/ocaml but lib/ocaml/shlibs), then I would add
symbolic links to there, rather than put libraries directly there and
get compatibility problems later. But symbolic links have their own
problems, and do not work well with Windows.

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