Version française
Home     About     Download     Resources     Contact us    
Browse thread
Portability of applications written in OCAML
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: Portability of applications written in OCAML
> Would that make -custom bytecode arch independent again ?

That's the idea, yes.

> how do you handle libraries with different exported symbols per arch ?

Typically, when interfacing an existing C library with Caml, you have
two libraries: the C library and a library containing the stub
functions for communication with Caml.  The latter must export the
same stub functions on all platforms, indeed, but it can then adapt to
variations in the underlying C library using #ifdefs and so on.

> Euh, ...
> is the member removal not done using the strip program ? 

Not at all.  I was talking about the following feature of Unix
linkers: when a ".a" library is statically linked, not all ".o" object
files contained in the library are linked and put in the executable,
but only those that define symbols actually referenced by the program.

> stripping ocaml
> bytecode executable is a very bad idea, as can be seen when trying to strip
> ocamldebug for example. Notice that ocamlc, ocamlopt and ocaml don't seem to
> suffer from this problem.

Yes, all bytecode executables produced with the -custom option must
not be stripped.  This is even mentioned in the manual, I think.

- Xavier Leroy