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

[Martin Lucina <martin@xxxxxxxxxx>]

On Tuesday, 19.05.2015 at 14:09, Peter Zotov wrote:
> >What can be done to fix the above? Should I be using a host
> >compiler built
> >and installed by OPAM rather than the system compiler
> >(4.02.1-1ppa3~precise
> >on Debian wheezy). [I'll try this and see if it helps...]
> 
> No. This is an issue with Lwt's discover.ml script. You're going in
> the right direction below, though using --enable-android-target
> for this is a bit awkward.

I'll see what I can do to fix discover.ml better, but given that I know
almost no OCaml it might take a while.

> 
> >
> >I tried to hack around the problem by using
> >--enable-android-target, that
> >causes discover.ml to succeed and the build then proceeds, failing on a
> >different problem:
> >
> >E: Failure("Expected built file '_build/src/unix/dlllwt-unix_stubs.so'
> >doesn't exist.")
> >
> >This is expected; the rumprun toolchain does not support dynamic
> >linking
> >and I have configured the ocaml-rumprun compiler with
> >-no-shared-libs. Is
> >there some way to tell OASIS to not expect any shared libraries to be
> >built?
> 
> Nope. OASIS is painfully inflexible, especially when cross-compiling.
> You can probably patch setup.ml so that it thinks that the current
> OCaml is built without dynlink, but this is package-specific.

Turns out it's a two-line patch, at least in the case of Lwt:

https://github.com/mato/opam-rumprun/commit/3d3a9f0b46a21370c7b619e14cbfddec90acf433

> >AFAICS there are multiple approaches being used in the wild and OCaml
> >upstream *claims* to include support for cross-compiling via -host and
> >-target, however that support is not actually functional?
> 
> Cross-compiling is not there yet. The switches are only half functional,
> if you're lucky.

Yeah, I figured that out after battling with it for a day or so, then found
your patches which mostly[*] worked.

[*: It seems that the Github mirror at ocaml/ocaml is a bit slow, I was
going to write about how I couldn't get your 4.02.02 compiler package to
work without patches, but it looks like the commit for PR#6266 has landed
on Github now, couldn't see it yesterday.]

> >For the rumprun support to be as user-friendly as possible, we
> >need an easy
> >way of switching the backend rumprun cross-compiler and linker used by
> >ocaml when the user wants to switch platforms or architectures. The
> >approach used by the android repository I based my work off
> >implies either:
> >
> >a) the user would have to *reinstall* the cross compiler
> >(specifying eg.
> >RUMPRUN_CC in the environment) and all packages using native code
> >whenever
> >they want to switch the backend compiler.
> 
> Correct. This is what opam-android uses.

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.

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