[Caml-list] Big executables from ocamlopt; dynamic libraries again

[tim@fungible.com (Tim Freeman)]

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