[m-users.] ARM Linux toolchain

Julien Fischer jfischer at opturion.com
Sat Feb 13 00:31:06 AEDT 2016

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.

The situation here is that you are trying to build a compiler that
targets ARM Linux on some other platform (presumably Linux x86 or
x86_64).  I'm not sure if anyone has ever tried doing that.

In principle, this should be possible but there's not really any
support for doing it, so it's like to be a fairly fiddly process.
Something along the following lines _might_ work:

    * configure as above
    * ensure that the executables in the util directory get replaced
      with the corresponding executables from a Mercury installed on
     the host system.
    * do the 'make' step through to completion
    * replace compiler/mercury_compile with one built for the host system.
    * do the 'make install' step

> arm-linux-gnueabihf-ranlib    libmer_browser.a
> echo > mer_browser.init
> mkinit -k mdb.c mdb.browse.c mdb.browser_info.c mdb.browser_term.c mdb.collect_lib.c mdb.cterm.c mdb.debugger_interface.c mdb.declarative_analyser.c
> mdb.declarative_debugger.c mdb.declarative_edt.c mdb.declarative_execution.c mdb.declarative_oracle.c mdb.declarative_tree.c mdb.declarative_user.c
> mdb.diff.c mdb.dl.c mdb.frame.c mdb.help.c mdb.interactive_query.c mdb.io_action.c mdb.listing.c mdb.name_mangle.c mdb.parse.c mdb.sized_pretty.c
> mdb.term_rep.c mdb.util.c mer_browser.c  >> mer_browser.init
> ../util/mkinit: 1: ../util/mkinit: Syntax error: word unexpected (expecting ")")
> /tmp/mmake.70HtEo:7334: recipe for target 'mer_browser.init' failed
> Should I somehow use a native util/mkinit instead?

See above.


More information about the users mailing list