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

[Martin Helm]

Am Freitag, den 21.10.2011, 20:04 +0200 schrieb 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.
> 
> 

I have to apologize that I had no chance to come back on that earlier
but was really busy with my daily job including last weekend. 
I started again looking in the configure and compilation process and
make myself more familiar with autoconf and friends and found a small
glitch with pcre.

In  configure.ac the check for the pcre library uses pcre-config but
does not respect that we are cross compiling, so it runs the existing
pcre-config of my build machine to get the switches and this returns of
course the worng paths like "-L/usr/lib64 -lpcre".

If we would check if we do a cross compilation with mingw it would be
possible instead to call correctly the cross compilers pkg-config to get
what we need:
i686-w64-mingw32-pkg-config --cflags libpcre
-I/usr/i686-w64-mingw32/sys-root/mingw/include  

i686-w64-mingw32-pkg-config --libs libpcre
-L/usr/i686-w64-mingw32/sys-root/mingw/lib -lpcre  

I think similar problems happen in other places also since I noticed for
example that configure finds the fltk on my build system whereas I do
not even have it available in the cross compilation environment and
tries to compile the opengl backend (I circumvent that with
--without-opengl but it points to a deeper problem), I have to
investigate that in more depth.