Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

[Philip Nienhuis]

John D wrote:
> -----Original Message-----
> From: Philip Nienhuis [mailto:address@hidden
> Sent: Wednesday, June 12, 2013 4:57 PM
> To: John D
> Cc: 'John W. Eaton'; address@hidden; 'Clemens Buchacher';
> 'Anirudha Bose'
> Subject: Re: Building on MinGW using MXE-built dependencies [WAS: Re:
> mxe-installer try 2]
>
> John D wrote:
> > -----Original Message-----
> > From: Philip Nienhuis [mailto:address@hidden
> > Sent: Wednesday, June 12, 2013 3:14 PM
> > To: John W. Eaton
> <snip>
> > > > Just out of curiosity: why are postgres and libodbc required anyway?
> > >
> > > I don't know that they are really needed. Are they? They were listed
> > > as dependencies of qt when I created my fork of MXE. If they are not
> > > needed, then we should drop the dependencies and stop trying to build
> > them.
> >
> > When I built Qt4 4.7.2 for mingw-32 a year or so ago, postgres wasn't
> > required. But maybe things changed.
> > I suppose I could simply comment out the postgres&   libodbc stuff
> > somewhere (have to search for it) and see how far I get. Perhaps too
> > easy, perhaps it works.
> >
> > ---
> > Removing it as a dependency from src/qt.mk will make it not bother to
> > try to compile postgresql I think - qt.mk will require some other
> > changes as well anyway.
>
> Indeed, I dropped postgresql, libodbc++ and freetds (and possibly sqlite can
> be dropped as well) from index.html and in the .mk files in src (grepping
> for those names) and qt now stops in configure, requesting a -platform
> option.
>
> Right at this moment I'm trying to find out what to fill in there using
> google. I found an interesting thread on qt4 dependencies and configure
> options here:
>     http://qt-project.org/forums/viewthread/23171
> but that's as far as I could get tonight.
>
> Maybe tomorrow I can pick up again.
>
> Philip
>
> ------
>
> If I skip both of qt and postgres (touch installed-packages
> qt/qscintilla/postgresql) I get the rest built up to octave - but fails in
> the configure of octave with a window coming up "conftest.exe - Entry point
> not found: The procedure entry point __addtf3 could not be located in the
> dynamic link library libgcc_s_dw2-1.dll.
>
> It appears to be failing the octave configure for each function of below
> (from the log):
> checking whether LSAME is called correctly from Fortran... no
> checking whether ISAMAX is called correctly from Fortran... no
> checking whether SDOT is called correctly from Fortran... no
> checking whether DDOT is called correctly from Fortran... no
> checking whether CDOTU is called correctly from Fortran... no
> checking whether ZDOTU is called correctly from Fortran... make[1]: ***
> [build-only-octave] Error 1

Did you try to build stable or development Octave?

Trying to get qt4 built is indeed painful. You solve one error, you get 
two or three seemingly unrelated ones back.

Maybe it is good to just evaluate what we got now.

Originally I started this thread because I figured that MXE would be a 
wonderful way to quickly and efficiently cross-compile all required 
Octave dependencies, so that testing & debugging Octave on MingW could 
be done by transplanting the completely built mxe-octave tree to 
Windows, add some required MinGW stuff, and then build Octave "natively".

That way debugging and re-building MinGW Octave would be much more 
efficient because one could avoid most of the tedious steps of building 
on Linux, make a dist tarball, updating octave.mk SHA1 entry, do a 
"blind" build, followed by transplanting to Windows, followed by 
installing and finally testing there, all of that for every small patch 
of Octave - maybe even just a one-byte change.
Instead, just configure/make followed by a ./run-octave would 
(hopefully) do. (But OK, maybe I'm too naive)
As all dependencies are still built using standardized mxe-octave, 
debugging and developing Octave itself would still be fairly predictable 
for the devs.

So I wonder whether it is worthwile to go the way of building everything 
on MinGW itself - I already expected that to be hard. And it is. It now 
goes beyond my own proficiency (and available time).

I'm in doubt on what to do now. I might try yo go back to my original 
plans, at the same time I'm prepared to help trying to build a 64-bit 
MinGW Octave, but for that I'd need clear instructions once I got 
mingw-64 set up (I already downloaded a binary mingw-64). But maybe that 
is also better done using cross-compiling all dependencies on Linux.

Philip