From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA31679; Wed, 15 May 2002 01:28:52 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA31675 for ; Wed, 15 May 2002 01:28:51 +0200 (MET DST) Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4ENSmn05228 for ; Wed, 15 May 2002 01:28:49 +0200 (MET DST) Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17]) by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id IAA03000; Wed, 15 May 2002 08:28:42 +0900 To: malekith@pld-linux.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] OCaml packaging problems In-Reply-To: <20020514135457.GB4521@ep09.kernel.pl> References: <20020514105452.B11894@pauillac.inria.fr> <20020514203954L.garrigue@kurims.kyoto-u.ac.jp> <20020514135457.GB4521@ep09.kernel.pl> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020515082840O.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 15 May 2002 08:28:40 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Michal Moskal > 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 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