Browse thread
[Caml-list] Big executables from ocamlopt; dynamic libraries again
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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@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