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 SAA09130; Sat, 16 Mar 2002 18:45:12 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA09269 for ; Sat, 16 Mar 2002 18:45:11 +0100 (MET) Received: from lobus.fungible.com (adsl-64-161-114-6.dsl.snfc21.pacbell.net [64.161.114.6]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g2GHj9v23481 for ; Sat, 16 Mar 2002 18:45:09 +0100 (MET) Received: by lobus.fungible.com (Postfix, from userid 1000) id 1FF307F48; Sat, 16 Mar 2002 09:42:55 -0800 (PST) Message-Id: <9601-Sat16Mar2002094255-0800-tim@fungible.com> X-Mailer: emacs 21.1.1 (via feedmail 8 I) Date: Sat, 16 Mar 2002 09:05:50 -0700 From-Tims-Fingers: true To: caml-list@inria.fr Subject: [Caml-list] Big executables from ocamlopt; dynamic libraries again From: tim@fungible.com (Tim Freeman) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk When I compile a simple "hello world" app using lablgtk, the resulting executable exceeds 800KB. With a few apps like this, my package will take offensively long to download, even over DSL. The exectuable seems to be including most of the lablgtk library in the executable, which makes sense because lablgtk is statically linked in the executable. This isn't a problem with lablgtk. A native code app that just prints "hello world" on standard output takes 5K bytes if written in C but 95K in ocaml. The GTK executable would be smaller if lablgtk were dynamically linked into it. I hear that a real shared library isn't an option because the present ocaml compiler can't generate position independent code. However, one can do dynamic linking on many machines without position independent code or a shared library; the dynamic linker just relocates the library at run time. I'd really rather write something in OCAML than the other languages available, but if the resulting executables are so huge that I can't distribute binaries, that's a problem. If I controlled the libraries myself, I could use the scaml patch from http://algol.prosalg.no/~malc/scaml/, but I'd much rather use the lablgtk that comes in Debian than package it myself, and I'd rather not stick my users with a redundant copy of the lablgtk library. Is there any reason there's no support for writing dynamically linkable libraries in OCAML? Hmm, if you memorized the MD5 checksum of the library at compile time, and checked it at run time, it could even be type safe. Or you could just memorize the MD5 of the signature of the library, in some sense; this would allow patches like the recent zlib double-free. If the library knows it's checksum, and the code loading it knows the expected checksum, then you can do this checking without computing a checksum at run time. -- 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