[Caml-list] dlopen win32 port

[Caml-list] dlopen win32 port

[Jeff Henrikson]

Hi caml-list,

I made the "dlopen" ocaml library compile under win32.  I don't have any idea how to integrate changes into the autotools scripts,
or if it is worth it to do so.  Opinions?

Win32 has functions that correspond nearly one to one with dlopen dlsym and dlclose.  The only compatability issue I can think of
are windows' fairly uniform use of stdcall for DLL functions, and the corresponding name mangling of foo(int x, int y) to _foo@4.
It seems like there should be some wrapping around this to make it disappear so that equal C files link the same on both platforms.
Would need to have a switch to turn it off for dlls that break the convention.  Haven't done that yet.

I have been trying to get a Mac port of this, but I am too much of newbie at MPW right now.  But I from what I've read I think
think the CFM model for dynamic linking is a bit more exotic.

Does anybody have a bulletproof way to unzip source code on Mac?  I used the obvious stuffit expander to unsit the ocaml source,
and after various control panel tweaking (Stuffit by default thinks Makefile.Mac is a picture for some reason) I still get CRLF
problems with :tools:make-opcodes.Mac.  There are at least two other build problems that I have used duct tape to fix.  (I'm using
the 3.02 tarball right now, the 3.01 mac makefiles had more errors)

Is it me or does the DoMake script have to start from scratch every time you make it?

> 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?


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

Re: [Caml-list] dlopen win32 port

[Xavier Leroy]

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

[Caml-list] dynamic linking ocamlopt?

[Jeff Henrikson]

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