Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Big executables from ocamlopt; dynamic libraries again
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: malc <malc@p...>
Subject: Re: [Caml-list] Big executables from ocamlopt; dynamic libraries again
On Mon, 18 Mar 2002, Jacques Garrigue wrote:

> From: (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.



To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: