Re: [Caml-list] Ocaml shared libraries

[Xavier Leroy <xavier.leroy@inria.fr>]

> 	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