Re: Cross compiling GNU Octave from GNU/Linux for Windows

[Martin Helm]

Am Freitag, den 21.10.2011, 13:18 -0400 schrieb John W. Eaton: 
> On 21-Oct-2011, Martin Helm wrote:
> 
> | After I succeeded some time ago to compile octave with mingw on windows
> | (3.4.3 and development version) it turned out that I really do not like
> | to do that since almost everything I do is done on GNU/Linux systems
> | (most of the time on openSUSE, sometimes on Debian) esp. if it comes to
> | development.
> | 
> | So the natural question was, why not cross compiling it.
> 
> Yes, I also want to do this and tried recently.
> 
> | I started a few
> | days ago to make myself a bit familiar with the mingw cross compiler
> | environment (did this on openSUSE) and were able to cross compile some
> | libraries from scratch and also octave.
> 
> I did not get very far, as I think most of Octave's dependencies are
> not very well designed for cross compiling.  My conclusion was that if
> I could just get all the dependencies built with MinGW, then I would
> put them in a place where the cross build of Octave could find them,
> then focus on the cross build of Octave and worry about cross building
> the dependencies later.

I did of course not compile all optional dependencies as a first step
just a minimal set like pcre, lapack and some others. Many basic
dependencies are satisfied by corresponding prebuilt rpm packages in
openSUSE for the mingw environment (readline I remember and some
others), I did not check right now but will investigate later what is
provided in Debian.

So my first try is not that different, I also considered just to take
some of the more special optional libs (I did not need to do that right
now) from Tatsuros build environment and place it in the sys-root of my
mingw cross compiler to make them available for the moment and also care
later to build them directly from the gnu/linux system.

> 
> | Since I noticed the configure script created by autogen.sh is not very
> | suitable for this, it was necessary to do some ugly (and dirty) hacks to
> | make this possible.
> 
> I think the only real problems are that the configure script has some
> tests that require running programs.  Rather than try to run them
> (perhaps with wine?) it would be best to try to provide defaults for
> cross compiling where needed.  The AC_RUN_IFELSE macro allows for
> this, but Octave's configure script just doesn't set a default often,
> and even then, the default really should depend in some way on the
> value of the host variable that is set when running configure for the
> cross build.
Almost none of that test compiles are performed anyway since the
configure script accepts that we are in cross compiling mode since I
pass the --host=i686-w64-mingw32 option, but for some features configure
still tries to compile and run something anyway exactly because of
missing defaults.

Some can be avoided by setting

octave_cv_fortran_integer_size=true gl_cv_func_gettimeofday_clobber=no

before configure.
IEEE 754 is set to false when cross compiling so it fails to configure.
But setting the corresponding ac variable octave_cv_ieee754_data_format
to true (or yes or what it was, I do now not sit in front of the system)
forces a test build/run of a code snippet, that is one hack where I set
it to true in the configure script and removed the code which makes the
test which compiles the code snippet (I am sure there is an easy clean
solution for that).
The test for fast integer math as it is now also introduces a problem
and I removed the test which is no very sophisticated solution.

Another problem at the end is when it starts building the files for
octave's info system it uses programs built before which are made for
the target platform instead for the build platform and therefor fails.

> 
> | If there is any interest at all in that I will summarize the problems I
> | found (and the hacks I applied) during this weekend for further
> | discussion to find a better and clean way to support that.
> 
> Yes, I'd be interested in helping you with this project.`
> 
> jwe

Thank you. 

I will report the proper details tomorrow, the few details above were
only to show the type of problems which happened at the beginning from
my memory without access to my PC were the build system lives and maybe
can find out a bit more until then.