From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Gerd.Stolpmann@darmstadt.netsurf.de,
Claude Marche <Claude.Marche@lri.fr>,
caml-list@inria.fr
Subject: Re: Portability of applications written in OCAML
Date: Tue, 22 Feb 2000 10:21:16 +0100 [thread overview]
Message-ID: <20000222102116.38250@pauillac.inria.fr> (raw)
In-Reply-To: <20000222091306.A19683@dpt-info.u-strasbg.fr>; from Sven LUTHER on Tue, Feb 22, 2000 at 09:13:06AM +0100
> 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
next prev parent reply other threads:[~2000-02-22 14:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-15 13:01 Claude Marche
2000-02-16 13:09 ` Jean-Francois Monin
2000-02-16 14:08 ` Claude Marche
2000-02-16 14:28 ` Jean-Francois Monin
2000-02-18 9:18 ` Patrick Goldbronn - SYSCO
2000-02-16 22:49 ` Gerd Stolpmann
2000-02-18 9:36 ` Xavier Leroy
2000-02-21 20:45 ` skaller
2000-02-22 8:13 ` Sven LUTHER
2000-02-22 9:21 ` Xavier Leroy [this message]
2000-02-22 23:43 ` Portability of applications written in OCAML: C stuff Max Skaller
2000-02-23 18:31 ` Markus Mottl
2000-02-24 2:55 ` Max Skaller
2000-02-24 14:44 ` Sven LUTHER
2000-02-24 15:04 ` Alan Schmitt
2000-02-24 23:51 ` Max Skaller
2000-02-25 8:37 ` Alan Schmitt
2000-02-25 16:58 ` skaller
2000-02-24 20:17 ` Gerd Stolpmann
2000-02-25 0:35 ` Max Skaller
2000-02-25 13:21 ` STARYNKEVITCH Basile
2000-02-17 8:05 ` Portability of applications written in OCAML skaller
2000-02-21 19:02 Don Syme
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000222102116.38250@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=Claude.Marche@lri.fr \
--cc=Gerd.Stolpmann@darmstadt.netsurf.de \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox