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

[Francois Berenger <berenger@riken.jp>]

On 02/21/2014 01:53 AM, Xavier Leroy wrote:
> 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.

Moreover, I think BSDs can install GNU make and that the corresponding 
command is simply gmake instead of make.

>> *** 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
>


-- 
Best regards,
Francois Berenger.