Re: [Caml-list] -ccopt -shared

[malc <malc@pulsesoft.com>]

On Fri, 7 Dec 2001, Xavier Leroy wrote:

> > > If you really want to create a shared library containing OCaml code
> > > and the OCaml runtime system, this can be done, but you need to use
> > > ocamlc -output-obj or ocamlopt -output-obj to package the OCaml code
> > > as a C object.
> > 
> >  And the resulting code will be PIC on x86 with a native compiler? 
> 
> No.  It will not be position-independent code.  But good dynamic
> linkers such as those of Linux and Windows do not require
> position-independent code; they can also load dynamically code
> containing absolute references.  This is a bit slower than dynamically
> linking pure PIC code, and prevents the sharing of the code segment
> between several processes that load the shared library, but it still works.
> 
Yes sharability is lost, and loading time should be worse (lots of stuff
to fix), the runtime speed however will be better. I have investigated
PICability of OCaml generated code (which is really a nobrainer to
implement on i386), and came to the conclusion that its not worth
it. OCaml uses much more absolute references than any C application.
Loosing ebx permanently, one other general register per  memory reference,
adding prologue to every function(one can get around that but erm...)  and
appending @PLT to every function call will have significant penalty on
OCaml native backend generated code speed. Then there is COPY_RELOC
problem, only SUN's and CVS binutils ld can omit generation of this type
of relocation.

And one more thing about sharability(which is the one and only argument in
favor of PIC) Windows never had it, and seems like no one is complaining.
They say Alpha doesnt have PIC either (will be interesting to know why)

> > Is it already usefull?
> 
> Depends what you need shared libraries for.  If your goal is to reduce
> memory consumption because many running processes share the library,
> then no, it's not useful.  But it *is* useful if your goal is to
> interface with another system that cannot statically link with your
> code and absolutely requires foreign code to be a shared library, such
> as Java's native method interface, or COM's "in-proc" components.
> 
> - Xavier Leroy

-- 
mailto:malc@pulsesoft.com

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