From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA24078; Sat, 1 Sep 2001 12:06:55 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA24365 for ; Sat, 1 Sep 2001 12:06:54 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f81A6qv04270; Sat, 1 Sep 2001 12:06:52 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA24203; Sat, 1 Sep 2001 12:06:52 +0200 (MET DST) Date: Sat, 1 Sep 2001 12:06:52 +0200 From: Xavier Leroy To: Jeff Henrikson Cc: caml-list@inria.fr Subject: Re: [Caml-list] dlopen win32 port Message-ID: <20010901120652.A24206@pauillac.inria.fr> References: <000401c13268$48473ba0$0b01a8c0@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <000401c13268$48473ba0$0b01a8c0@mit.edu>; from jehenrik@yahoo.com on Fri, Aug 31, 2001 at 06:00:01PM -0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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