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

[Peter Zotov <whitequark@xxxxxxxxxxxxxx>]

On 2015-05-19 11:50, Martin Lucina wrote:
> Rumprun provides a unikernel stack with a POSIXy (NetBSD-HEAD) 
> userspace
> and can run on Xen, QEMU/KVM, bare metal and POSIX userspace.  The
> resulting Mirage + rumprun unikernel will thus be able to run on all of 
> the
> platforms rumprun supports.
Nice!

>     $ OCAMLFIND_TOOLCHAIN=rumprun ocaml setup.ml -configure --prefix
> /home/mato/.opam/system/x86_64-rumprun-netbsd/ --disable-libev
>
> Results in:
>
>     not checking for pkg-config
>     not checking for libev
>     testing for pthread: ........................... unavailable
>     not checking for glib
>
>     The following recquired C libraries are missing: pthread.
>
> The reason this happens is that discover.ml is invoking the following
> compile command:
>
> /home/mato/projects/rumpkernel/rumprun/app-tools/rumprun-xen-cc
> -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c
> -I/usr/include -o /tmp/lwt_stubf12ac7.o
> -I/home/mato/.opam/system/x86_64-rumprun-netbsd/lib/ocaml
> /tmp/lwt_stubf12ac7.c
>
> Note the inclusion of -I/usr/include -- this is presumably there so 
> that
> the system OCaml compiler's headers are available, however it results 
> in a
> conflict between the NetBSD headers provided by rumprun and the system
> headers.
>
> 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 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.

> General questions:
>
> 1) Is this the right strategy for building an OCaml cross-compiler and
> integrating with OPAM?
>
> 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.

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

> b) we would have to provide different opam packages of the compiler and
> native libraries (Lwt) for each platform/arch combination supported by
> rumprun. This is unmanageable.
This could be done with a script (horrible but functional).

There was some talk over teaching OPAM that one package might be 
installed
in several 'variants', but there is no code to do that yet at all, and 
it
will probably be a substantial amount of work to integrate this with
the dependency solver.

opam-android would /greatly/ benefit from that as well, for much
the same reasons.

> 2) Is there an easy way to switch ocamlc and the various other parts of 
> the
> build system(s) involved into a verbose mode so that I can see what
> compilers are being invoked and why they fail? At the moment I'm using
> `strace' for this :-/
ocamlfind c -verbose; ocamlc -verbose

> All ideas and help much appreciated,
>
> Cheers,
>
> Martin
>
> [1] http://wiki.rumpkernel.org/Repo%3A-rumprun
> [2] https://github.com/whitequark/opam-android
--
Peter Zotov

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel