Re: [Caml-list] dlopen win32 port

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> > Xavier Leroy wrote on 8/24:
> >"dynamic_loading" branch on the OCaml development sources
> >(camlcvs.inria.fr).  I'll post more information about it once I'm
> >happy with the result, to get some feedback on the design.
> 
> I checked out these sources and did some superficial diffing of it,
> and it wasn't obvious to me which the salient changes were.  I think
> I was diffing source that was too old though (3.01).  A big mess.
> Is this code for dynamic linking FFI code like DlOpen, or for the
> general problem of incorporating typing info and etc from one Caml
> module into another at runtime?

I haven't looked at this DlOpen library yet, so I'll pass.  But here
is a short description of what I implemented recently.  I thought I
posted it already on this list, but can't find it in the archives, so
here we go again.

  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.

  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.

  Obligatory backward compatibility note: this new mechanism doesn't
  deprecate the -custom mode, which is still supported.  No existing
  code should break.

- Xavier Leroy
-------------------
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