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 PAA12262; Mon, 17 May 2004 15:45:53 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA11290; Mon, 17 May 2004 15:45:51 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from gatekeeper.elmer.external.excelhustler.com (gatekeeper.excelhustler.com [68.99.114.105]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4HDjnEV027036; Mon, 17 May 2004 15:45:50 +0200 Received: from chatterbox.elmer.internal.excelhustler.com (unknown [192.168.0.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "chatterbox.elmer.internal.excelhustler.com", Issuer "excelhustler.com" (not verified)) by gatekeeper.elmer.external.excelhustler.com (Postfix) with ESMTP id 6D99DE01A0; Mon, 17 May 2004 08:45:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 9E8085C006; Mon, 17 May 2004 08:45:47 -0500 (CDT) Received: from chatterbox.elmer.internal.excelhustler.com ([192.168.0.12]) by localhost (chatterbox [192.168.0.12]) (amavisd-new, port 10025) with ESMTP id 27052-05; Mon, 17 May 2004 08:45:44 -0500 (CDT) Received: from wile.internal.excelhustler.com (wile.internal.excelhustler.com [192.168.1.34]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 60D955C004; Mon, 17 May 2004 08:45:44 -0500 (CDT) Received: by wile.internal.excelhustler.com (Postfix, from userid 1000) id 3A8BCA06C; Mon, 17 May 2004 08:45:44 -0500 (CDT) Date: Mon, 17 May 2004 08:45:44 -0500 From: John Goerzen To: Xavier Leroy Cc: Eric Stokes , caml-list@inria.fr Subject: Re: [Caml-list] Ocaml shared libraries Message-ID: <20040517134544.GB6669@excelhustler.com> References: <20040517102254.A22324@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040517102254.A22324@pauillac.inria.fr> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at excelhustler.com X-Miltered: at nez-perce with ID 40A8C20D.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 invalidate:01 libs:01 dynamically:01 sunos:01 sunos:01 movies:99 non-issue:01 4...:01 dynlink:01 api:01 ocaml:01 ocaml:01 bytecode:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, May 17, 2004 at 10:22:54AM +0200, Xavier Leroy wrote: > With shared libraries, any update on the shared lib would immediately > invalidate all executables that use it. This is the well-known "DLL > hell" problem, just exacerbated by the very strict consistency > checkings done by the OCaml linker. So, feature 2- above is really > not applicable to OCaml as it is today, and static linking is much > more usable than dynamic linking of shared libs. I'm not quite sure that conclusion follows from your premise. Let's say we have an OCaml executable and needs to link with certain OCaml libraries. Couldn't the dynamic loader embedded in that executable, whatever form it may take, check with the libraries it's dynamically linking with to make sure the interfaces remain the same? > As for feature 1- (smaller executables), I'm not convinced this is a > major issue. I'm old enough to remember the introduction of shared > libraries in the Unix world (in SunOS 4). At that time, the saving in > disk space was significant: disks were small (a complete SunOS 4 > install could fit in as little as 100 Mb) and the size of executables > wasn't negligible compared to the size of data files. Times have > changed, however: disk space has increased much faster than executable > sizes, and the disks on a modern machine are mostly filled with data > (think MP3 and movies :-), making executable sizes a non-issue. There are plenty of situations where this is not the case. For instance: 1. Handheld devices (think Sharp Zaurus, re-flashed iPAQ, or other units that run Linux) 2. Other embedded systems 3. Limited-storage systems (thin clients, etc) 4. Limited-RAM systems A little more on #4... on *nix platforms, at least, the code of a .so is usually shared among all processes that use it. > Feature 3- (dynamic code loading) is already available in bytecode > through the Dynlink API. I understand there's a demand for having it > in native-code as well, and that might be possible without too much fuss, > at least on selected operating systems. It exists, but it's not exactly to the point where you can use it to load in any arbitrary library; specifically, you can only load libraries that are specifically written to register their functions with your app somehow. -- John ------------------- 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