Re: [Caml-list] Big executables from ocamlopt; dynamic libraries again

[malc <malc@pulsesoft.com>]

On Mon, 18 Mar 2002, Jacques Garrigue wrote:

> From: tim@fungible.com (Tim Freeman)
> 
> > >A major problem with using dynamic linking with ocaml (in particular
> > >with native code), is that your program come cut into small pieces,
> > >and you must be sure that they are all compatible.
> > 
> > How is ocaml different from C in this regard?  One difference is that
> > ocaml is younger and therefore changing faster, but eventually that
> > won't be true any more.  Are there other difference?
> 
> In short: C doesn't make sure that they are compatible.
> If they are, this will work, otherwise, undefined behaviour.
> Programmers and users are responsible for checking (by hand!) that the
> API didn't change in an incompatible way.
> 
> If you want to have both security and allow linking everytime it's
> safe, then you would need to do lots of type-checking at link-time
> (runtime for dynamic linking). Basically that every module you depend
> on has an interface at least as good as what you need, checking type
> by type. If you've got a look at the size of some .cmi's, you may
> realize that including required types in executables may require
> potentially huge sizes. And type-checking is sometimes too slow.
> 
> As a fall-back solution, there is MD5 hashing. The problem is that
> you're then mixing information for all the contents of a module.
> Any change will produce a new incompatible hash value.
> For instance, every time you add a function to a library, it becomes
> incompatible. And there are new functions in every release of ocaml.

If by this you mean unique suffixes for symbols (Module_funcname_123)
and value address positions withing module's data storage, then there
is a workaround which i implemented in my shared patch, so that produced
code is less dependant on such seemingly irrelevant things as
adding/removing/swaping places of global visible functions and variables.

<skip>

-- 
mailto:malc@pulsesoft.com

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