caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: 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 09:13:06 +0100	[thread overview]
Message-ID: <20000222091306.A19683@dpt-info.u-strasbg.fr> (raw)
In-Reply-To: <20000218103603.51298@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Fri, Feb 18, 2000 at 10:36:03AM +0100

On Fri, Feb 18, 2000 at 10:36:03AM +0100, Xavier Leroy wrote:
> Claude Marche asks:
> 
> >One idea could be distributing bytecode: is it true the any bytecode
> >can be executed on any architecture and OS as soon as the right
> >ocamlrun is used? (Even under non unix OSs like Microsoft-Windows or
> >Mac-OS?) 
> 
> For MacOS, there are some problems with end-of-line being represented
> by different control characters in MacOS and in Unix and Windows.  So,
> newlines in program output are broken.
> 
> For MacOS and Windows, there is also the fact that file path names are
> represented differently.  So, if your program manipulates file names,
> even though the Filename module, the bytecode may not work well under
> a different OS.
> 
> I think the easiest way to distribute an OCaml application is as
> sources, plus binaries for a couple of popular architectures
> (typically, Linux/Intel and Windows).  Novice users can pick the
> binaries, and experienced users should have no problems installing
> OCaml for compiling your application.
> 
> Gerd Stolpmann wrote:
> > My suggestion: Every modern operating system can link libraries dynamically.
> > This is also possible for the parts of the OCaml libraries written in C
> > which need to be available in the runtime system.
> 
> Right, I have been considering dynamic loading of C libraries as an
> alternative to -custom.  This would allow, among other benefits,
> dynamic loading of Caml libraries that contain some C code.

Would that make -custom bytecode arch independent again ? how do you handle
libraries with different exported symbols per arch ?

> There are some portability issues with old or exotic versions of Unix,
> but I think it can be made to work under, say, Linux, Solaris,
> Digital/Tru64 Unix, and Windows.  There are some issues still to be
> resolved, however, such as how to build shared C libraries in a
> portable fashion, perhaps by using the GNU libtool package.
> 
> > - Only libraries needed for the application are loaded into memory;
> >   the memory footprints become much smaller
> 
> Yes and no, because static linking under C is able to remove members
> of the .a archive that are not referenced, while dynamic loading
> typically loads everything.  But memory footprint of code is not much
> of an issue these days.

Euh, ...

is the member removal not done using the strip 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.

Friendly,

Sven LUTHER




  parent reply	other threads:[~2000-02-22 10:53 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 [this message]
2000-02-22  9:21       ` Xavier Leroy
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=20000222091306.A19683@dpt-info.u-strasbg.fr \
    --to=luther@dpt-info.u-strasbg.fr \
    --cc=Claude.Marche@lri.fr \
    --cc=Gerd.Stolpmann@darmstadt.netsurf.de \
    --cc=Xavier.Leroy@inria.fr \
    --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;
as well as URLs for NNTP newsgroup(s).