How can SWI-Prolog be cross-compiled for ARM?

[Carles Araguz]

Hi!

I'm trying to build SWIPL from sources to an ARM-based platform (Linux). I've followed the build procedures detailed here but once I execute the ./configure script I end up with an error that I am not able to understand. This is what I executed:

./configure --build=i686-pc-linux-gnu --host=arm-linux-gnueabi --prefix=/path/to/cross-compile/forlder

I've copied the contents of the log here: config.log

And the output of the execution (stdout / stderr) here: ./configure output

Does anyone know what could be wrong? I might be missing some libraries (for ARM at least) but I've been unable to find out which ones.

Thanks in advance!

Carles

PS: If I am able to finish the whole building process and have a working binary, I plan to write a detailed guide and publish it somewhere. I can send you the reference, link etc.

[Jan Wielemaker]

Dear Carles,

The simplest solution is of course to compile it on the ARM itself. Did
that on my Rasberry Pi, and it works just fine. Ok, to compile
everything with all packages allows you to go for dinner while it
compiles :-)

The configure files are not really written for cross-compilation.
Various tests require testing runtime behaviour, which means you must be
able to run the executable. autoconf allows giving additional rules to
assume something if it is not possible to run the binary. That is what
it complains against: it tries to figure out whether the real time
clocks work. At some point, the system was ported to a platform that did
provide the interfaces, but those were just stubs and thus a runtime
check is the only way to figure out whether they are supported or not.

The only tested cross-compilation setting is for Windows from Linux,
but here we can use wine to run the binaries.

The above should be fixed using appropriate assumptions. Once fixed
though, you must also find workarounds for doing the Prolog
bits of the compilation. This can be done by using the host Prolog
system, provided that the version is exactly the same and that the
word-size (32 vs 64) is the same. Endian-ness may differ; this is
compensated for by the saved-state loader.

For short, it is all doable. It requires some experience with
setting up cross-compilation though. If you do it, I'm happy to
merge the changes provided that the normal and Windows compilation
do not break or are easily fixed again.

Cheers --- Jan

On 05/27/2014 01:01 PM, Carles Araguz wrote:
> Hi!
>
> I'm trying to build SWIPL from sources to an ARM-based platform (Linux).
> I've followed the build procedures detailed here

> <http://swi-prolog.org/build/unix.html> but once I execute the

> ./configure script I end up with an error that I am not able to
> understand. This is what I executed:
>
> |
> ./configure --build=i686-pc-linux-gnu --host=arm-linux-gnueabi
> --prefix=/path/to/cross-compile/forlder
> |
>
> I've copied the contents of the log here: config.log

> <http://pastebin.com/6Znqs9QT>

> And the output of the execution (stdout / stderr) here: ./configure

> output <http://pastebin.com/xfWPG2Bf>

> Does anyone know what could be wrong? I might be missing some libraries
> (for ARM at least) but I've been unable to find out which ones.
>
>
> Thanks in advance!
> Carles
>
> PS: If I am able to finish the whole building process and have a working
> binary, I plan to write a detailed guide and publish it somewhere. I can
> send you the reference, link etc.
>

> --
> You received this message because you are subscribed to the Google
> Groups "SWI-Prolog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swi-prolog+...@googlegroups.com
> <mailto:swi-prolog+...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/swi-prolog.
> For more options, visit https://groups.google.com/d/optout.

[Carles Araguz]

Thanks Jan!

My target platform has no building capabilities (i.e. GCC), so I'll try to cross-compile it by:

A) Patching the configure.in as to disable all runtime tests and/or hardcode the result of these tests executed manually on the target platform.

B) Running configure with options to skip those checks.

          or C) Generating a new ./configure from scratch (would it be possible/helpful?) in order to allow cross-compilation. 

Once I get it, I'll try to post the process somewhere.  

Cheers,

Carles

[Jan Wielemaker]

On 05/29/2014 10:33 AM, Carles Araguz wrote:
> Thanks Jan!
>
> My target platform has no building capabilities (i.e. GCC), so I'll try
> to cross-compile it by:
>
> A) Patching the configure.in as to disable all runtime tests and/or
> hardcode the result of these tests executed manually on the target
> platform.
>
> B) Running configure with options to skip those checks.
>
> or C) Generating a new ./configure from scratch (would it be
> possible/helpful?) in order to allow cross-compilation.

I wouldn't go for (C). You should only need to so something sensible for
the AC_TRY_RUN tests. Most of the tests only need the compiler. If your
only concern is to get it compiled, you could also just do the whole
installation on a fully equipped ARM (e.g., a Raspberry Pi) and copy
config.status. Run it on the cross-compilation environment and fix
the details in the generated Makefile. The disadvantage is that this
is a one-shot process, i.e., it will get you a binary quite quickly,
but you have to maintain it separately and it doesn't help people
who want to do cross-compilation elsewhere much.

> Once I get it, I'll try to post the process somewhere.

If you do it the clean way, i.e., patching configure.in and Makefile.in,
please send a patch or GitHub pull request.

Cheers --- Jan

>
> Cheers,
> Carles

[Oleh]

The ARM config is very interesting.

There is one problem with the cross compile, the saved state is machine dependent (to some extend) and the emulator is needed to create it. For cross-compile under Linux for Windows the Wine-tool is used and then it works.

If we could have an option to create a saved state with a tool which does not require emulation of target host, then it would be easier.

Cheers
Oleh

[Jan Wielemaker]

On 06/27/2014 09:14 AM, Oleh wrote:
> The ARM config is very interesting.
>
> There is one problem with the cross compile, the saved state is machine
> dependent (to some extend) and the emulator is needed to create it. For
> cross-compile under Linux for Windows the Wine-tool is used and then it
> works.
>
> If we could have an option to create a saved state with a tool which
> does not require emulation of target host, then it would be easier.

There are basically two options:

- Make sure that the native swipl has the same word-length (32/64 bits)
and use the native swipl for creating the boot file.
- Omit creating the boot file and ensure that it is created on the
target machine as a post-install step.

The second is probably the simplest and most robust way out. It may
provide some issues with building (some of) the packages. These should
all be solvable by additional post-install steps.

With some knowledge of Make and autoconf, this should all be doable.
Ideally,
the cross-compilation should create a native executable that performs all
post-install work (native to provide maximum portability).

Cheers --- Jan

> Cheers
> Oleh
>
>
> On Thursday, May 29, 2014 10:33:32 AM UTC+2, Carles Araguz wrote:
>
> Thanks Jan!
>
> My target platform has no building capabilities (i.e. GCC), so I'll
> try to cross-compile it by:
>

> A) Patching the configure.in <http://configure.in> as to disable

> all runtime tests and/or hardcode the result of these tests
> executed manually on the target platform.
>
> B) Running configure with options to skip those checks.
>
> or C) Generating a new ./configure from scratch (would it
> be possible/helpful?) in order to allow cross-compilation.
>
> Once I get it, I'll try to post the process somewhere.
>
> Cheers,
> Carles
>