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 QAA13447; Mon, 17 May 2004 16:27:32 +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 QAA11822; Mon, 17 May 2004 16:27:30 +0200 (MET DST) Received: from plover.csun.edu (plover.csun.edu [130.166.1.24]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4HERSSH010804; Mon, 17 May 2004 16:27:29 +0200 Received: from puffin.csun.edu (puffin.csun.edu [130.166.1.21]) by plover.csun.edu (MOS 3.4.6-GR) with ESMTP id BDR34526; Mon, 17 May 2004 07:27:27 -0700 (PDT) Received: from [130.166.10.91] (s010n091.csun.edu [130.166.10.91]) by puffin.csun.edu (MOS 3.4.4-GR) with ESMTP id BTH00574 (AUTH eric); Mon, 17 May 2004 07:27:26 -0700 (PDT) In-Reply-To: <20040517102254.A22324@pauillac.inria.fr> References: <20040517102254.A22324@pauillac.inria.fr> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <50A49C6A-A80E-11D8-B8C2-000A95A1E69A@csun.edu> Content-Transfer-Encoding: 7bit Cc: caml-list@inria.fr From: Eric Stokes Subject: Re: [Caml-list] Ocaml shared libraries Date: Mon, 17 May 2004 07:27:24 -0700 To: Xavier Leroy X-Mailer: Apple Mail (2.613) X-Miltered: at concorde with ID 40A8CBD0.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 brittle:01 type-safe:01 cross-module:01 brittle:01 invalidate:01 libs:01 sunos:01 sunos:01 movies:99 non-issue:01 dynlink:01 api:01 fragile:01 ocaml's:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Yes, I realized when I started this thread that all of these issues would arise. I know it is a nasty problem to do type safe shared libraries. The feature I am most interested in is #2, upgradeability, #3 is a close second. So building a less brittle but still type safe linker would be necessary. My question really is, do you all have any interest in doing so. It seems like it would be an interesting project with practical benefits. On May 17, 2004, at 1:22 AM, Xavier Leroy wrote: >> As the director of a shop who is using Ocaml to do real work >> (yes I know, research is more important :P), I would really like to >> be able to build a shared library out of code that I have written in >> Ocaml, and link other Ocaml programs to it. [...] > > I'm not sure which aspect of shared libraries you're interested in. > Unix shared libraries or Windows DLL offer the following features: > 1- Smaller executables through code sharing. > 2- Upgradeability: upgrade the shared library and (with luck) all > executables that refer to it are automatically upgraded. > 3- Dynamic loading of code in a running program. > > There is however one big difference between C and OCaml, which is that > OCaml has type-safe linking. The linker checks that clients of a > library were typed and compiled against the interface and cross-module > optimization information of the library. > > As it is done today, this check is rather brittle: any change in the > library interface or optimization information cause it to fail and > require a recompile of the client modules. > > For static linking, this is not too bad: a package management > framework such as GODI can automate the recompilation of clients when > the library changes. More importantly, you need to bring things in > sync only when you're rebuilding your client: already compiled > programs continue to work, since they embark their own version of the > library. > > 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. > > 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. > > 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. > > So, in summary: shared libraries are simply too fragile, especially > when combined with OCaml's type-safe linking. This is such a big > problem that the drawbacks of static linking (bigger executables) > appear very minor in comparison. > > - Xavier Leroy > > ------------------- > 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 > ------------------- 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