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

["Benoît Vaugon" <benoit.vaugon@gmail.com>]

Hi,

For cross-compilation, have you seen opam cross-compiler packages for 
win32 and win64: https://github.com/vouillon/opam-windows-repository, 
and for android: https://github.com/vouillon/opam-android-repository? 
These repositories also provide opam packages for some cross-compiled 
libraries, which is not simple because it requires both the host ocaml 
compilers and the cross-ones. Itmight be interesting to combineour 
efforts...

As with your compiler, linking bytecode with -custom doesn't work with 
these compilers too, due to the same reason.

Probably just a naive question: to solve this problem, don't you think 
it would be possible to write a piece of OCaml code replacing the call 
to dlopen()/dlsym() in the OCaml compiler, that manually reads the C 
libraries and list the exported symbolsat compile time without loading them?

Benoît.

Le 21/02/2014 08:53, Adrien Nader a écrit :
> 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).
>