Re: [Caml-list] [RFC] Remaining changes for cross-compilation support in OCaml

[Xavier Leroy <Xavier.Leroy@inria.fr>]

Hi Adrien,

> Roughly one year ago, late Wojciech Meyer and I started working on the
> integration of a set of patches aimed at enabling the OCaml compiler to
> be used for cross-compilation.
> 
> Some of the patches so far have caused issues to some people. 

s/some people/the core OCaml dev team/

> **************************** Further Goals ****************************
> - cross-compile the compiler: build a native Windows toolchain on Linux
> - canadian cross support: ${build}, ${target}, ${host} are all
>   different, i.e. on Linux, build a toolchain that runs on Windows 64b
>   but targets Windows 32b or a different architecture/OS like ARM Linux.

That could be a nice touch if it's not too much extra work.  The issue
was discussed at the last OCaml dev team meeting that Wojciech
attended, and we agreed that some scenarios were less important than
others, e.g. nobody really needs to compile from a 32-bit host for a
64-bit target.

> ****************************** Approach ******************************
> *** A cross-compiler requires a native toolchain of the same version ***
> A working _native_ compiler toolchain of the _exact_ same version as the
> cross-toolchain is needed, both when building the cross-toolchain and
> when using it; the main reason was camlp4 but I believe it is still a
> valid restriction

Perhaps less so now that camlp4 is split off.  The alternative is to
configure for the host, populate boot/ with a ocamlrun and standard
library appropriate for the host, then reconfigure for the target, and
finish the build.

> *** Give up the restriction to POSIX for makefiles ***
> Either remove compatibility with BSD makes, or move GNU-make-isms to
> "GNUMakefile", BSD-makes-isms to "BSDMakefile" and common data to
> "Makefile.common" with the GNU/BSDMakefile files being the
> "entrypoints".

The unanimous message from the OCaml dev team is to commit on GNU make
and forget about compatibility with other variants of make.  BSD
people will forgive us, and it looks like the only sane way to merge
the Unix and Windows makefiles and support all the cross-compilation
scenarios.

> *** Use configure-defined variables instead of "ocaml{c,opt}"... ***
> The creation of the cross-compiler will rely on a native toolchain on
> ${build}. As such, ./configure will locate that toolchain and store its
> paths. This forbids any call like "./ocamlopt"; everything must rely on
> the paths found by configure.

See above: this might not be necessary.

> *** Use Int64.t in the compiler instead of Nativeint ***
> Currently, OCaml uses Nativeint to handle all the integers in the code
> that is being compiled. The "native" is for ${build}, not for ${target}.
> With a 64b host and 32b target, OCaml will output its values over 64
> bits in the assembly and ld will then complain and truncate them.
> Move to Int64.t instead and delay the conversion to the right bitness
> until code emiting.

Constant propagation and maybe other passes of the compiler also need to
take bitsize into account.

If you're going this way, it's not Int64 the appropriate substitute
for Nativeint: it's Targetint, defined as Int32 or Int64 depending on
target bitsize.  (This can be expressed with first-class modules.)

There might be other ways if we assume bitsize(host) >= bitsize(target).

> *** For bytecode, assume C libraries contain the required primitives ***
> When doing linking for bytecode with -custom, OCaml will dlopen() the
> corresponding library and dlsym() the primitive as an early check for
> their availability at runtime.
> Quite obviously, this fails for cross-compilation and the only solution
> I can think of is to disable the check completely. 

Probably there is no choice.  But it pains me to move link-time errors
to run-time (more exactly, program startup time).  If we program in
OCaml rather than Python, it's also for the early error detection.

- Xavier Leroy