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

[Adrien Nader <adrien@notk.org>]

Hi Xavier,

On Thu, Feb 20, 2014, Xavier Leroy wrote:
> > ****************************** 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.

Camlp4 was clearly the main component to require this but I have also
been wondering about ocamldoc and ocamldep which can break because of
new syntax.

For now this requirements is probably the safe approach. Note that this
restriction only checks for x.y.z versions, not for the tags than can
come after 'z'; it made working with trunk too difficult.

Also, as a packager, I prefer this. I find that the other approach makes
packaging more difficult.

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

OK; I liked pmake and its descendants, partly because of their clean
syntax with true flow control and thought it could be left as a
possibility. Anyway, I will take that route.

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

I believe you refer to configuring for host, populating boot and then
configuring again for target. It's something I hadn't thought of and
could work nicely. I need to experiment with this a bit and see how
things would work out.

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

I wish everyone (at least everyone doing devlopment) would have a 64b
machine but it's not the case unfortunately. ='( 

This is not an area in the compiler I know much, if any, about. This can
most probably be worked on separately from the other patches; if someone
wants to contribute and can do the changes, it will be much
appreciated. :) 

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

I see no cross-platform solution either. However, I expect most people
to build natively before doing cross-compilation and that should catch
most link errors hopefully (that's a small consolation).

-- 
Adrien Nader