[Caml-list] dynamic linking ocamlopt?

["Jeff Henrikson" <jehenrik@yahoo.com>]

This part sounds like exactly what dlopen does:

>   The goal of this work is to allow bytecode to refer to
>   libraries such as Unix, Str, etc, without having to be linked in
>   -custom mode.
>
>   In other terms: currently, when a library such as Unix
>   (which contains C stub code in a library archive libunix.a) is linked in,
>   ocamlc generates a custom runtime system statically linked with
>   libunix.a, and sticks the Caml bytecode at the end of this custom
>   runtime system.  This has two drawbacks: 1- the bytecode is no longer
>   machine-independent, since it is attached to a native executable (the
>   custom runtime system); 2- you need a C compiler and linker around,
>   which many Windows users don't have.
>
>   With the new scheme, ocamlc simply generates a machine-independent
>   bytecode executable that says "by the way, I'll need the libunix C
>   stub code"; and ocamlrun dynamically links libunix.so and resolves the
>   references to C external functions.  Voila, bytecode is
>   machine-independent, and no C compiler is required.

That much has obvious implementation, and that's what dlopen is.  But this is beyond its scope:

>   This also allows to load dynamically .cma files that refer to C stub
>   code, either at the toplevel (#load) or with Dynlink.  The C stub code
>   is loaded dynamically in a fully transparent fashion.  It's quite cool
>   to type #load "labltk.cma";; in the toplevel and have LablTk working
>   like a charm, without all these pesky "ocamlmktop" commands.

Not knowing the ocaml internals well, it's not obvious to me that the dlopen behavior is the only thing missing to get this
working.  Without contradictory information, I would presume that it isn't in fact obvious to make this work for ocamlopt code.
(Isn't basically all the type info of ocamlopt code stripped out at compile time?)

But you obviously know the internals better than me!


Jeff Henrikson


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr