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 AAA30906; Wed, 15 May 2002 00:52:46 +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 AAA30892 for ; Wed, 15 May 2002 00:52:45 +0200 (MET DST) Received: from moutng1.kundenserver.de (moutng1.kundenserver.de [212.227.126.171]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4EMqin04190; Wed, 15 May 2002 00:52:44 +0200 (MET DST) Received: from [212.227.126.160] (helo=mrelayng0.kundenserver.de) by moutng1.kundenserver.de with esmtp (Exim 3.22 #2) id 177l9w-0003Mo-00; Wed, 15 May 2002 00:52:44 +0200 Received: from [80.129.103.194] (helo=gate.gerd-stolpmann.de) by mrelayng0.kundenserver.de with asmtp (Exim 3.22 #2) id 177l9v-0005EZ-00; Wed, 15 May 2002 00:52:43 +0200 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id 183B2CCCF; Wed, 15 May 2002 00:52:41 +0200 (CEST) Received: from ice (localhost [127.0.0.1]) by ice.gerd-stolpmann.de (Postfix) with ESMTP id 635551AD77; Wed, 15 May 2002 00:52:41 +0200 (MEST) Date: Wed, 15 May 2002 00:52:40 +0200 From: Gerd Stolpmann To: Xavier Leroy Cc: caml-list@inria.fr Subject: Re: [Caml-list] OCaml packaging problems Message-ID: <20020515005240.A629@ice.gerd-stolpmann.de> References: <20020430111657.A18782@pauillac.inria.fr> <20020430200405.A16880@dpt-info.u-strasbg.fr> <20020514105452.B11894@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20020514105452.B11894@pauillac.inria.fr>; from xavier.leroy@inria.fr on Tue, May 14, 2002 at 10:54:52 +0200 X-Mailer: Balsa 1.2.4 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 2002.05.14 10:54 Xavier Leroy wrote: > 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). > > 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). Traditionally, Unixes try to minimize the directories that contain code, i.e. executables and (later) shared libraries are stored in only a few directories. Today people tend to justify this way of managing code without realizing that it is the consequence of a design decision of the operating system, and not naturally the best choice. The point is that important parts of the program loader run in userland, and not inside the kernel. Especially searching the libraries is done for every started program again, because it is not possible to have an index that could speed this process up. At least an automatic index is not possible (you would need hooks on file system operations for it, and that would require modifications in the kernel, e.g. a filesystem with database capabilities). Some Unixes have such an index, but it must be manually updated (ldconfig). This means: The lack of a certain facility is the reason why Unix organizes the directories by its operational needs, and not "by package", or in a completely different way. > 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. In my opinion, there is no real reason why ocaml should follow the Unix example, because the ocaml loader needs not to manage the whole system, and has much lower scalability requirements. Currently I have 9 directories in my ld.conf, and even if I had twenty directories I would not notice any significant startup deferrals. (Yes, the search needs quadratic time, but the file system cache helps very much to keep the costs low.) Furthermore, for users with much higher requirements it is possible to implement the index like some of the Unix loaders do: by an ld.cache that must be updated by starting an update program. Finally, I want to point out that ocaml views the C libraries primarily as _dynamic_ libraries and not _shared_ libraries, so a shared directory is conceptually misleading. The cma is shared, not the C library behind it. Ideally, there would be a unique ID that joins the cma and the C library, and that makes the association between the cma and the C library exclusive. (So no other cma can load the C library, e.g. because I have installed several versions of the same module with the danger of a name clash.) Well, again we would need database capabilities to do the job right... Nobody can generate such a unique ID for us. > (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.) Which error? Too less directories! > So, to summarize, I strongly suggest the following approach for RPMs > or Debian packages: > - The main Caml package can add one or two lines to ld.conf, > e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages) > and /usr/local/lib/ocaml/shlibs (for local stuff) > - Packages for additional Caml libraries install their shared libraries > in /var/lib/ocaml/shlibs, either directly or via a symlink. > > This is simple, consistent with C shared libraries, and supports > deinstallation of additional Caml libraries without any hassle. Yes, for packaged ocaml installations this is the simplest solution. But not everybody uses such installations, and for manually maintained systems this way introduces another source for errors. My summary is different: The Unix way of handling shared library is driven by operational requirements (fast library lookup), and is conceptually not the best choice. In a better world, it would be possible to link programs with libraries in a very controlled way, but that would require database capabilities on the filesystem layer. However, for the needs of a small subsystem like ocaml, it is not hopeless to maintain the required index tables manually. Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 45 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ---------------------------------------------------------------------------- ------------------- 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