Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Ocaml shared libraries
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Eric Stokes <eric.stokes@c...>
Subject: Re: [Caml-list] Ocaml shared libraries
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