Re: [Caml-list] Caml on intel-OSX

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: John Skaller <skaller@users.sourceforge.net>
> On Thu, 2005-06-09 at 18:20 +0200, padiolea@irisa.fr wrote:
> 
> > > Lol! no, it is a simple question. Can I make a bytecode program
> > > and just ship it an expect it to run? No. So what else is required?
> > 
> > I guess that if your bytecode program require some external libraries,
> > such as for instance if you do a "open Dbm"  then you must
> > have too this library.
> > I think that ocamlrun only include code to handle the Pervasive
> > library.
> 
> The code uses only (a) the standard library (Hashtbl and so on),
> (b) the Unix library, and (c) Bignums. Therefore the bytecode
> only requires support to be found in the standard distribution.
> 
> I have a suspicion that one needs to '-custom' link somehow,
> to make a suitable single bytecode interpreter. The desire
> here is to *avoid* building Ocaml from source on the
> target platform, instead to use pre-built binaries,
> or, at worst, build these binaries from source,
> excluding the full Ocaml toolkit -- the compiler isn't
> required since the program is already compiled
> to bytecode.

In theory, it should be enough to have ocamlrun, and the dlls in
stublibs.
The an ocaml bytecode executable, linked _without_ -custom, could be
executed as:
  $ setenv CAML_LD_LIBRARY_PATH /path/to/stublibs
  $ ocamlrun myprogram
(Of course you need everything to be compiled from the same ocaml
distribution.)

The problem is that there is no support to compile only bits and
pieces of the ocaml distribution. And there is little point to do
that: once you've compiled the ocamlrun, all the ocaml tools will
compile without a glitch.
This said, you can try to do this by hand. On Unix, ocamlmklib is
required, so this would be:
  $ ./configure
  $ make coldstart
  $ (cd tools; make ocamlmklib)
  $ (cd otherlibs/unix; make libunix.a)
  $ (cd otherlibs/num; make libnums.a)
Then copy ocamlrun, dllunix.so and dllnums.so to public places.

On windows/msvc, the process is even shorter as ocamlmklib is not
used (but I didn't check):
  $ make -f Makefile.nt runtime
  $ cd otherlibs/unix; make -f Makefile.nt dllunix.dll
  $ cd ../nums; make -f Makefile.nt dllnums.dll
However there is little point, as binaries are available:
Just get an ocaml binary distribution, and only keep ocamlrun and all
the dlls (including ocamlrun.dll).

> Both myself and my friend are trying to build the Felix
> system on diverse platforms, and make it available easily
> to potential users: this includes not only Unix like systems,
> but also Windows, Apple, and IBM platforms. At present, he 
> has got his hands on an Intel/Mac platform for a very limited time,
> (at the actual release conference) previously we worked
> on an IBM PPC64/Linux platform, G4 and G5 OSX platforms,
> and I'm trying to make the system build on native 
> Windows Win32 (XP) without Cygwin, using  MSVC++ compiler 
> and prebuilt Ocaml .. as well as trying to make both
> a Godi and Debian packages ... I wait with dread the release
> of 64 bit XP ..

What you're trying to say is not completely clear to me, especially
as you mix "sane" unix systems with "insane" msvc++.
But the whole point is that, if you're satisfied with bytecode, you
only need ocamlrun and the dlls to run any ocaml bytecode executable.
No need to recompile anything on the target platform. There is only
one exception to that: I believe that executable for windows should
link with the windows version of unix.cma. Ideally you would be
able to do that even on a unix system, but unfortunately ocamlc checks
that no external functions are missing at link time, which makes this
impossible (we need a flag to disable that check...) So for the time
being, an unix executable will run on any unix platform, and a windows
executable will run on any windows platform (including 64-bit XP, when
it will be supported). Also it should be possible to link on windows objects
produced on unix (and vice-versa). To do that you only need ocamlc
and all the cma's.

Actually it might be a good idea to provide such minimal binary
platforms for a variety of systems.

Jacques Garrigue