[opam-devel] [MirageOS-devel] Cross-compiling OCaml, Mirage OS for rumprun, OPAM integration

[Nicolas Ojeda Bar]

Just to add my 2 cents,

I am currently hacking away at a RISC-V cross-compiler and so have
been looking into the cross-compilation support quite a bit.
I found that a recent commit to the 4.02 branch to be quite promising, see

https://github.com/ocaml/ocaml/commit/f1f28e10ae4f7b76e7b92a2e72ce1fb8a33d86a9

You can try this out by doing

opam switch 4.02.0+trunk

A couple of things that you need in order to use the cross-compilation support:
- You need the host ocaml system to be the same version as the version
of the cross-compiler (in this case, 4.02)
- You need an ANSI C cross-compiler named <target>-gcc.
- It is not possible to cross-compile between different word sizes
(this is related to the use of Nativeint in the compiler and quite
orthogonal to the build system issues).

With this switch, I was eventually able to cross-compile the
native-code compiler (and runtime system) to RISC-V.  Unfortunately I
cannot yet test anything because I still need to port some assembly
bits to plug in the runtime system into the generated programs, but
the assembly generated looks promising.

Best wishes,
Nicolas


On Tue, May 19, 2015 at 4:22 PM, Thomas Gazagnaire
<thomas at gazagnaire.org> wrote:
>> And, as I just found out now, it's not just the native packages, it's *all*
>> packages that need to be rebuilt. So, for Mirage I'd have to produce
>> -rumprun variants of all its dependent packages, right? This would include
>> teaching the "mirage configure" script about them.
>
> We already partly do that to cross-compile the C stubs for Xen (such as gmp for the TLS stack to work on Xen). The upcoming 2.5.0 release of mirage will have improved support for this. See gmp-xen[1] and some ugly ocamlfind hackery to pass the right options at link time, used by mirage configure[2] when generating the Makefile.
>
> Clearly the situation will not scale well as we will have to patch every package using C stubs. I'm looking forward to have full support cross-compilation in the whole toolchain (to start with the build tools).
>
> --
> Thomas
>
> [1]: https://github.com/ocaml/opam-repository/tree/master/packages/gmp-xen/gmp-xen.6.0.0
> [2]: https://github.com/ocaml/opam-repository/blob/master/packages/zarith/zarith.1.3/files/xen_linkopts.patch
> [3]: https://github.com/mirage/mirage/blob/master/lib/mirage.ml#L2248
>
>>
>> This begs the question, why did you use the approach of building the
>> cross-compiler as a normal OPAM package, rather than as a compiler package?
>>
>> If I understand correctly how "OPAM switch" works, then the latter option
>> would at least get rid of the need to deal with the -android (or -rumprun)
>> renaming of packages since each compiler has its own set of packages.
>>
>> Obviously, there'd still have to be some way of getting
>> the OCAMLFIND_TOOLCHAIN and/or other cross-compilation patches into the
>> system but at first glance it seems like it would be more flexible than
>> adding suffixes to package names.
>>
>> Thoughts?
>>
>> Martin
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-devel at lists.xenproject.org
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel