|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] [opam-devel] Cross-compiling OCaml, Mirage OS for rumprun, OPAM integration
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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > _______________________________________________ > opam-devel mailing list > opam-devel@xxxxxxxxxxxxxxx > http://lists.ocaml.org/listinfo/opam-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |