Re: Questions/Issues trying to cross-compile Octave

[John W. Eaton]

[I'm moving this discussion here from the help list.  --jwe]

On 17-Jan-2012, Corbin Champion wrote:

| I have figured out what --host is for and what value to set it to.

Right, the terminology is a bit confusing with build, host, and
target.  Build is the system you are running the compiler on, host is
the system the generated binaries will run on.  As I understand it,
target is rarely used.  It is normally the same as host, but can be
different if you are cross compiling a cross compiler that will be
used to generate code for a system different from the host (for
example, you are building a copy of GCC on an x86 system that will be
able to run on a sparc system and that will itself be a cross compiler
that generates code for a sparc system).  Maybe
http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html explains it
better.

| stuck with errors like
| 
| checking whether fstatat (..., 0) works... configure: error: in `/home/corbin/
| applications/
| 
| octave-3.4.3':
| configure: error: cannot run test program while cross compiling
| 
| I understand why that would be, since it cannot run the test code on the arm
| system and see whether it works.
| 
| So, what is the correct work-around?  I assume I need to tell it explicitly
| whether this works or not, but how?  I hope I can still use ./configure as
| opposed to doing it manually, since it looks like ./configure is doing quite a
| bit before this error. 

One way to handle this is to provide defaults for all uses of
AC_RUN_IFELSE and similar macros.  That way there is some value that
is guessed when cross compiling.  Unfortunately, there is usually not
one default that makes sense for all possible host systems, so
something else must be done.

If all tests in the configure script used AC_CACHE_VAL properly, then
you could preset the cache values for tests that can't be run based on
your knowledge of the host you are compiling for.  Then those tests
would be bypassed and you'd get the right values.  Doing this will
require some work, but it is the direction I'd like to head in.  The
configure script needs some cleanup anyway, and making it properly use
cache values would be a good start.

Note that even if it is possible to run the configure script on the
host system and then

Another issue is the use of pkg-config scripts to get values in the
configure script.  These will surely fail for cross compiling, so we
need to do something different for that.

Are you also cross compiling the dependencies?  If so, it would be
great if you could share your experiences here.

I'm interested in getting this working because it could greatly speed
up MinGW builds of Octave.  Running shell scripts like configure and
libtool is painfully slow on Windows, at least in my experience.

jwe