Browse thread
PIC
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2005-12-27 (12:23) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] PIC |
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 <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net