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

[tim@fungible.com (Tim Freeman)]

>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