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 EAA25662; Mon, 18 Mar 2002 04:35:54 +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 EAA24507 for ; Mon, 18 Mar 2002 04:35:53 +0100 (MET) Received: from lobus.fungible.com (adsl-64-161-114-6.dsl.snfc21.pacbell.net [64.161.114.6]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2I3ZoD07632 for ; Mon, 18 Mar 2002 04:35:50 +0100 (MET) Received: by lobus.fungible.com (Postfix, from userid 1000) id 5208F7F48; Sun, 17 Mar 2002 19:33:26 -0800 (PST) Message-Id: <1191-Sun17Mar2002193326-0800-tim@fungible.com> X-Mailer: emacs 21.1.1 (via feedmail 8 I) Date: Sun, 17 Mar 2002 18:29:42 -0700 From-Tims-Fingers: true To: garrigue@kurims.kyoto-u.ac.jp Cc: caml-list@inria.fr In-reply-to: <20020318101225C.garrigue@kurims.kyoto-u.ac.jp> (message from Jacques Garrigue on Mon, 18 Mar 2002 10:12:25 +0900) Subject: Re: [Caml-list] Big executables from ocamlopt; dynamic libraries again References: <9601-Sat16Mar2002094255-0800-tim@fungible.com> <20020318101225C.garrigue@kurims.kyoto-u.ac.jp> From: tim@fungible.com (Tim Freeman) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >Actually this is quite the opposite: dynamic linking >includes the whole library (but not in the executable), while static >linking only includes needed parts. In particular dynamic linking >without code sharing (using patched code) use more memory at runtime >than static linking. I agree. Even with the tradeoff you describe, I prefer the dynamic linking. I'm not too worried about memory at runtime; another 5 or 10MB will go unnoticed. If the code isn't used and there's a memory crisis, the code will get paged out. But the speed of the modems is limited and the space on the disk bites you even when you aren't running the program, so the size of the download matters more in my opinion. >The unfortunate thing is that the structure of the LablGTK library >creates lots of spurious dependencies. I see the same sort of thing happening in /usr/lib/ocaml/stdlib.a, so lablgtk is not alone there. If you make an object, you load oo.o from stdlib.a, which defines an unrelated function that uses random numbers, so static linking then grabs random.o. >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? >Static linking considerably improves that, since your program will no >longer depend on ocaml being installed, and the versions of its >different components. The C people find it prudent to offer both options. What is different about the ocaml situation? >..with the current MD5 approach, the checking is too version >dependent... Can someone point me to a description of the current MD5 approach? >And this nullifies the zlib example: the newly compiled version would >not be compatible with existing executables! Is there something wrong with just checksumming the signature to decide whether the code is compatible? That would still be more sensitive than I'd like, since adding to the signature ideally would not require people using the package to recompile, but it ought to support the zlib example. -- Tim Freeman tim@fungible.com; formerly tim@infoscreen.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