Re: Questions/Issues trying to cross-compile Octave

[Corbin Champion]

I have been able to cross-compile BLAS, LAPACK and run the LAPACK BLAS tests to prove it works now.  I did nothing more than I have described so far to get that to work.  Now need to cross compile PCRE the correct way.  Can you confirm that BLAS, LAPACK and PCRE are the only required dependencies?  I will worry about others later.

Thanks,
Corbin

On Fri, Jan 20, 2012 at 10:09 PM, Corbin Champion <address@hidden> wrote:

After failing to build LAPACK by running make at the top because LAPACK build tries to build and then run some tests to make sure LAPACK will work (problem is they are built for the host/target arch, but it tries to run it on the build machine which won't work), I explained the problem to the LAPACK team and this is what I got...

"The top level of the LAPACK build system was not designed to be used with a cross compiler, and as you found out, attempts to execute some test programs from the host shell.  You can build the library only by running make from the SRC directory (i.e. cd SRC;make) and that should work fine."

I haven't proved this works yet, but I thought I would give you the heads up.

Corbin

On Thu, Jan 19, 2012 at 10:43 PM, Corbin Champion <address@hidden> wrote:

Building the fortran reference implementation of BLAS using the toolchain I built generated no errors.  Will worry about performance and using an optimized version later.  Have to test though, but I have confirmed it used my android version of gfortran, so that is good.

On Jan 19, 2012 10:24 PM, "Corbin Champion" <address@hidden> wrote:

Great feedback!  Need to understand autoconf better to fully grasp your reply, but I get the gist of it and can dig deeper.  Obviously interested in any improvements you have for the configure script, even if experimental. 
About dependencies... These are the three I think I have to cross compile.  PCRE, BLAS and LAPACK.  Is that right?  Yes, I am working on cross compiling them, but am early in the process.  I got PCRE cross compiled for Android by using the Android build system following another's path.  This is not ideal at all.  I want to get it and the others built by simply using the configure scripts and makefiles included with their source.  I have built an Android standalone toolchain that also supports fortran compilation (not standard) and have tested it with some simple experiments.  I need to try doing that along with setting...

   export PATH=path_to_my_modified_toolchain/bin:$PATH
   export CC=arm-linux-androideabi-gcc

and see how that flies, but I just got the toolchain supporting fortran working with a basic example and did trying shooting the moon and compiling Octave before considering dependencies.  I will continue to provide updates as I work through this.

Thanks,

Corbin

On Jan 19, 2012 7:51 AM, "John W. Eaton" <address@hidden> wrote:

[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