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 UAA27768; Sat, 1 Sep 2001 20:39:15 +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 UAA27722 for ; Sat, 1 Sep 2001 20:39:14 +0200 (MET DST) Received: from ligarius-fe0.ultra.net (ligarius-fe0.ultra.net [146.115.8.189]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f81IdDv09800; Sat, 1 Sep 2001 20:39:13 +0200 (MET DST) Received: from vaiobambino (d72.dial-8.cmb.ma.ultra.net [209.6.71.72]) by ligarius-fe0.ultra.net (8.8.8/ult/n26500/mtc.v2) with SMTP id OAA26191; Sat, 1 Sep 2001 14:39:11 -0400 (EDT) From: "Jeff Henrikson" To: "Xavier Leroy" , Subject: [Caml-list] dynamic linking ocamlopt? Date: Sat, 1 Sep 2001 14:47:37 -0400 Message-ID: <000901c13316$91c098e0$0b01a8c0@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20010901120652.A24206@pauillac.inria.fr> Importance: Normal Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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