Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: Sven LUTHER <luther@d...>
Subject: Re: Portability of applications written in OCAML
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.