Re: [Caml-list] Ocaml shared libraries

[John Goerzen <jgoerzen@complete.org>]

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