From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA16614; Mon, 18 Mar 2002 11:46:43 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA31194 for ; Mon, 18 Mar 2002 11:46:42 +0100 (MET) Received: from comtv.ru (comtv.ru [217.10.32.4]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2IAkej15623 for ; Mon, 18 Mar 2002 11:46:41 +0100 (MET) Received: from [10.0.66.9] ([10.0.66.9] verified) by comtv.ru (CommuniGate Pro SMTP 3.5.7) with ESMTP id 2546977; Mon, 18 Mar 2002 13:46:17 +0300 Date: Mon, 18 Mar 2002 13:46:36 -0500 (EST) From: malc X-Sender: malc@home.oyster.ru To: Jacques Garrigue cc: tim@fungible.com, caml-list@inria.fr Subject: Re: [Caml-list] Big executables from ocamlopt; dynamic libraries again In-Reply-To: <20020318142017J.garrigue@kurims.kyoto-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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. -- 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