caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: Claude Marche <Claude.Marche@lri.fr>, caml-list@inria.fr
Subject: Re: Portability of applications written in OCAML
Date: Wed, 16 Feb 2000 23:49:22 +0100	[thread overview]
Message-ID: <00021700444302.30469@ice> (raw)
In-Reply-To: <14505.19990.196972.627775@sun-demons>

On Tue, 15 Feb 2000, Claude Marche wrote:

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

As far as I know: Yes. I did it already, and it worked even for systems
with different endianess. But I did it only for Unixes.

>If yes, anyone interested in using the application would
>need only to install the suitable ocamlrun for its architecture/OS
>combination.  It would allow any potentially interested user to try
>the application, and in case he finds it suitable for its need, he
>would be motivated to install ocaml for compiling from the sources and
>getting a faster application.
>
>For this to work, a kind of archive of various versions of ocamlrun
>should exist somewhere on the web, allowing to choose the right
>architecture/OS, also the right ocaml version, the right libraries
>like libc 5 or 6 or glibc.

Good idea.

>Nevertheless, there is a problem for applications that use other
>libraries like unix, str, nums, threads, that need to be compiled in
>-custom mode. If I understand well, binaries compiled with -custom
>contain the native code of the interpreter itself, so are not portable
>anymore. Techically speaking, is it possible to build an ocamlrun
>interpreter that contains those libraries statically linked?

This is possible by using the -make-runtime option.

But: This is not the best solution, as the number of libraries is growing,
and every time a new library (even a new version) would be needed by an
application, also new bytecode interpreters for all platforms would be
necessary. With two consequences:

1) The interpreters become very large, and there will be certainly people
   saying that OCaml is a big fat all-memory-eating language

2) The interpreters for platforms which are not everybody's darling will
   rapidly become too old to execute many applications.

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. The runtime system consists
of three parts:

1) The bytecode interpreter
2) The additional C-libraries
3) A startup routine which initializes the interpreter and configures the
   additional primitives available by 2)

There are no problems with parts 1 and 2 and dynamic libraries. Unfortunately,
part 3 is a generated C function, i.e. a different version is needed for every
combination of C-libraries. If we want dynamic libraries part 3 must be
replaced by a configurable dynamic loader. This is not too difficult, I think
I can write one (at least for Unix); the task of the dynamic loader is 
reading the list of necessary primitives from the bytecode file, loading the
associated libraries, and setting up the table that maps the primitives to
object-code symbols.

If this is done, we can link part 1 and the new loader that replaces part 3 to
the new, generic main executable which is able to run EVERY application for
which the necessary dynamic libraries are available.

So:

- For every platform, we need only one generic bytecode interpreter and one
  set of shared libraries

- Only libraries needed for the application are loaded into memory; the memory
  footprints become much smaller

- If new libraries are available, it is possible to compile them independently
  of the other libraries

- Multiple versions of the same library can easily be supported.

- It is often not necessary to recompile the libraries if a new version
  of the OCaml interpreter is available (at least if symbol-level 
  compatibility is given; the C FFI did not change often in the past).

>If this is technically feasible, I would like to know people who are
>interested in using this for distribution of their own application in
>bytecode form. Moreover, for building this archive of ocamlrun
>binaries, many people are needed to cover a wide range of
>architecture/OS combinations. I have access myself to PCs under Linux
>(Redhat distribution) and SPARC/Solaris 2.7, that's all.

Interested. I have some Web applications, and some TK applications.

I can offer 
 - Linux with libc5
 - Linux with glibc6.0
 - Linux with glibc6.1
   (Yes, I had problems to run OCaml applications compiled for glibc6.0 under
    glibc6.1!)
 - FreeBSD 3.3
 - Solaris 2.6
 - AIX 4.2

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------



  parent reply	other threads:[~2000-02-17 23:36 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 [this message]
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
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=00021700444302.30469@ice \
    --to=gerd.stolpmann@darmstadt.netsurf.de \
    --cc=Claude.Marche@lri.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).