caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] -ccopt -shared
       [not found] <200112030940.fB39eYA28293@ploum.inria.fr>
@ 2001-12-03 14:57 ` Christophe Raffalli
  2001-12-04 12:20   ` Xavier Leroy
  0 siblings, 1 reply; 6+ messages in thread
From: Christophe Raffalli @ 2001-12-03 14:57 UTC (permalink / raw)
  Cc: caml-list


When using ocaml (native or bytecode) are we allowed to use -ccopt -shared to
use shared library ?

When doing so (using lablGL), the program crashed (during dynamic linking or
runtime initialization) when compiled with the native compiler but worked with
the bytecode compiler ?

What's going on ?

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
-------------------
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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Caml-list] -ccopt -shared
  2001-12-03 14:57 ` [Caml-list] -ccopt -shared Christophe Raffalli
@ 2001-12-04 12:20   ` Xavier Leroy
  2001-12-04 20:27     ` Vitaly Lugovsky
  0 siblings, 1 reply; 6+ messages in thread
From: Xavier Leroy @ 2001-12-04 12:20 UTC (permalink / raw)
  To: Christophe Raffalli; +Cc: caml-list

> When using ocaml (native or bytecode) are we allowed to use -ccopt -shared to
> use shared library ?

Watch out: with gcc at least, the -shared option means "create a
shared library", not "use shared libraries".  The latter is the
default behavior; no need for additional flags.

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.

- 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Caml-list] -ccopt -shared
  2001-12-04 12:20   ` Xavier Leroy
@ 2001-12-04 20:27     ` Vitaly Lugovsky
  2001-12-04 23:27       ` malc
  2001-12-07 21:23       ` Xavier Leroy
  0 siblings, 2 replies; 6+ messages in thread
From: Vitaly Lugovsky @ 2001-12-04 20:27 UTC (permalink / raw)
  To: Xavier Leroy; +Cc: caml-list

On Tue, 4 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? Is it 
already usefull?


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Caml-list] -ccopt -shared
  2001-12-04 20:27     ` Vitaly Lugovsky
@ 2001-12-04 23:27       ` malc
  2001-12-07 21:23       ` Xavier Leroy
  1 sibling, 0 replies; 6+ messages in thread
From: malc @ 2001-12-04 23:27 UTC (permalink / raw)
  To: Vitaly Lugovsky; +Cc: caml-list

On Tue, 4 Dec 2001, Vitaly Lugovsky wrote:

> On Tue, 4 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? Is it 
> already usefull?

-ccopt -shared merely notifies ocaml driver to pass -shared to C driver.
I think you are confusing issues here.

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Caml-list] -ccopt -shared
  2001-12-04 20:27     ` Vitaly Lugovsky
  2001-12-04 23:27       ` malc
@ 2001-12-07 21:23       ` Xavier Leroy
  2001-12-08  0:53         ` malc
  1 sibling, 1 reply; 6+ messages in thread
From: Xavier Leroy @ 2001-12-07 21:23 UTC (permalink / raw)
  To: Vitaly Lugovsky; +Cc: caml-list

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

> 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


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Caml-list] -ccopt -shared
  2001-12-07 21:23       ` Xavier Leroy
@ 2001-12-08  0:53         ` malc
  0 siblings, 0 replies; 6+ messages in thread
From: malc @ 2001-12-08  0:53 UTC (permalink / raw)
  To: Xavier Leroy; +Cc: Vitaly Lugovsky, caml-list

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-12-08  0:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <200112030940.fB39eYA28293@ploum.inria.fr>
2001-12-03 14:57 ` [Caml-list] -ccopt -shared Christophe Raffalli
2001-12-04 12:20   ` Xavier Leroy
2001-12-04 20:27     ` Vitaly Lugovsky
2001-12-04 23:27       ` malc
2001-12-07 21:23       ` Xavier Leroy
2001-12-08  0:53         ` malc

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).