From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 65E5DBB81 for ; Tue, 27 Dec 2005 13:23:10 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jBRCN9aa016990 for ; Tue, 27 Dec 2005 13:23:10 +0100 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 NAA23961 for ; Tue, 27 Dec 2005 13:23:09 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jBRCN7w2016981; Tue, 27 Dec 2005 13:23:08 +0100 Received: from rosella (ppp33-4.lns1.syd2.internode.on.net [59.167.33.4] (may be forged)) by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id jBRCN1ic098193; Tue, 27 Dec 2005 22:53:02 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] PIC From: skaller To: Xavier Leroy Cc: caml-list@inria.fr In-Reply-To: <43B1116C.5060407@inria.fr> References: <1135476423.28426.45.camel@rosella> <43B1116C.5060407@inria.fr> Content-Type: text/plain Date: Tue, 27 Dec 2005 23:23:01 +1100 Message-Id: <1135686181.10470.38.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43B1322D.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43B1322B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 3.09:01 -fpic:01 ocaml:01 plug-ins:01 lgpl:01 loader:01 -fpic:01 ocamlopt:01 loader:01 bytecode:01 unix:01 wrote:01 sourceforge:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Tue, 2005-12-27 at 11:03 +0100, Xavier Leroy wrote: > > I notice Ocaml 3.09 has -fPIC option. Thanks! This is a step > > towards dynamic loading in native code. Thanks for your summary! > Encapsulation of compiled OCaml code as a shared library that can be > called from C is possible, on x86 at least. [] > This is a very good approach to use OCaml code from other languages > (e.g. Java) or as plug-ins (e.g. in Apache). Indeed! If I understand correctly, this requires redistribution of "LGPL with Linking Exception" parts of Ocaml only? > The reason it works particularly well for x86 is that dynamic loaders > for x86 (both under Unix/Linux and Windows) can relocate arbitrary > code, not necessarily PIC code. This is unfortunately not the case > for all target architectures. > In particular, dynamic loaders for > x86_64 (AMD64) are much less forgiving. I suspect you're being polite .. 'broken' seems to the correct term ;( The same techniques should work for the x86_64 as the x86 .. just making sure 64 bit values are supported (by the loader and ELF formats) should be enough. > The -fPIC option to ocamlopt > you mention was added to the AMD64 code generator in an attempt to > generate "more position-independent" code. However, it does not quite > work yet. A difficulty is the paucity of documentation on what, > exactly, the Linux AMD64 dynamic loader can relocate. I see. Ok, thanks for that info. Having looked into this myself .. I'm not surprised .. Sigh. Is the ia64 any better? > Dynamic loading of OCaml code from OCaml code raises many other > issues. Type safety, version compatibility, etc being a few. But one can work around this problem, perhaps messily and riskily, if the codes can be loaded and connected together with C glue. > It is currently supported for bytecode only, and will not be > available for native code in the forseeable future. I have already > discussed this on this list earlier. Yes, thanks. I hope I covered the combinations reasonably well, so your responses are fairly clear summary of the situation, which is what I was looking for: thanks! -- John Skaller Felix, successor to C++: http://felix.sf.net