[m-users.] ARM Linux toolchain

[Peter Wang]

On Sat, 13 Feb 2016 00:31:06 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Vladimir,
> 
> On Fri, 12 Feb 2016, Vladimir Komendantskiy wrote:
> 
> >       Passing
> >
> >           --with-llds-base-grade=none
> >
> >       to configure should do this for you.
> > 
> > 
> > This works, thanks! There is a new error then:
> > 
> > ../scripts/mgnuc --grade hlc.gc     --c-debug --no-ansi   --        -c mercury_signal.c -o mercury_signal.o
> > mercury_signal.c: In function ‘MR_init_signal_action’:
> > mercury_signal.c:133:8: error: ‘MR_signal_action {aka struct sigaction}’ has no member named ‘no’
> >      act->MR_SIGACTION_FIELD = handler;
> 
> That's why I said tools/configure_mingw_cross would probably require
> other changes, it sets the configure variable
> 'mercury_cv_sigaction_field' to "no", which is what you seem to be
> encountering above.  (Actually, the actual configure script requires
> changes here as well.)
> 
> > which seems to require setting the value of MR_SIGACTION_FIELD to
> > sa_handler in runtime/mercury_conf.h. In any case, that worked for me.
> > So far, we are done with compile-time errors.
> > 
> > What fails then is util/mkinit. It is supposed to be a native binary
> > in the make script. It is definitely an ARM executable though. The
> > message is as follows:
> 
> IIRC, tools/configure_mingw_cross was intended for use *on Windows*
> systems; if you wanted a Linux-Windows cross compiler you build the
> system on Windows and then replaced the executables with Linux ones (as
> per README.MinGw-cross).  mkinit being a Windows (or in your case ARM)
> executable is what is expected.

You run configure_mingw_cross on a Linux host and build on Linux,
producing a Mercury installation FOR Windows (executables and
libraries).  You can then substitute the Windows binaries with Linux
binaries to get a Mercury cross-compiler.

IIRC it only just barely works in this case because when building for
Windows the executables will have a ".exe" suffix, and not be found on a
Linux host.  e.g. the mkinit step will not run "util/mkinit.exe" but
instead call "mkinit" on the PATH.

It would be nice to teach the build system about cross-compilation but I
expect it will not be much fun.

BTW, as an alternative you may consider using PRoot with QEMU.
http://proot.me/

Peter