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

[John D]

-----Original Message-----
From: Philip Nienhuis [mailto:address@hidden 
Sent: Wednesday, June 12, 2013 6:00 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 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


----

I got octave (without the  GUI) to compile under native mingw !
And better yet if I cd into i686-pc-ming32/bin and run octave, it even runs!

I compiled without the qt and qt scintilla dependencies, however did note
that it looks for freetype, so that should be added as a dependency for the
octave.mk file.

Also, I had to set the PKG_CONFIG_PATH to usr/i686-pc-ming32/lib/pkgconfig
otherwise it wouldn't find the libraries during configure.

I think there is something wrong with pkg-config at the moment as when I run
it standalone (in debug output mode)
address@hidden ~/mxe-octave
$ ./usr/bin/pkg-config.exe --debug --list-all
Error printing enabled by default due to use of output options besides
--exists or --atleast/exact/max-version. Value of --silence-errors: 0
Error printing enabled
Adding virtual 'pkg-config' package to list of known packages
Cannot open directory
'/home/jdonoghue/mxe-octave/usr/i686-pc-mingw32/lib/pkgconfig' in package
search path: No such file or directory

But the path is there, and contains the .pc files.
When I set the PKG_CONFIG_PATH env variable there and run pkg-config, it
displays all the known libraries as expected.


For Qt, using configure.exe seems to be at least getting me through
configuration ok (I had to remove a lot of options that configure knows but
configure.exe doesn't understand) and then it fails in make:
make -C
'/home/jdonoghue/mxe-octave/tmp-qt/qt-everywhere-opensource-src-4.8.3' -
j '1'
make[2]: Entering directory
`/home/jdonoghue/mxe-octave/tmp-qt/qt-everywhere-ope
nsource-src-4.8.3'
C:/MinGW/msys/1.0/home/jdonoghue/mxe-octave/tmp-qt/qt-everywhere-opensource-
src-
4.8.3/bin/qmake
C:/MinGW/msys/1.0/home/jdonoghue/mxe-octave/tmp-qt/qt-everywhere
-opensource-src-4.8.3//projects.pro  -o Makefile -spec win32-g++
Could not find mkspecs for your QMAKESPEC(win32-g++) after trying:^M
 
C:/MinGW/msys/1.0/home/jdonoghue/mxe-octave/usr/i686-pc-mingw32\mkspecs

Not sure why its looking there for the mkspecs rather than in the Qt
distribution, but it is a step closer.