Re: Policy, location of .cma files in binary packages, and dynlink...

[Stéphane Glondu <steph@glondu.net>]

Stefano Zacchiroli a écrit :
> In an ideal scenario, OCaml would work precisely as it does now for the
> programmer, but store in the finally linked executables and libraries
> only references to objects that will then be loaded dynamically at
> runtime. If that were true, than your analogy with C would stand.

I think this is achievable: one could write a wrapper script around
ocamlc that would generate a stub which would (dynamically) load the
.cm{o,a}'s instead of generating an executable embedding them. To
achieve maximal sharing, the stub would only embed a restricted standard
library (basically anything needed to dynlink), and the runtime and
other externals would be in .so's.

This is technically challenging and can be done outside of INRIA's
jurisdiction. However, a problem still exits, as Xavier said¹:

> 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.

Therefore, doing this by default in Debian now is too risky IMHO, with
the current interface consistency checking.

When this checking is revised, allowing more flexibility and removing
the necessity of "everything must be rebuilt", the shared library scheme
will be reasonable. But I am somewhat pessimistic for this change in a
near future.

¹
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html


-- 
Stéphane