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

[Philip Nienhuis]

John D wrote:

<snip>

> I got octave (without the  GUI) to compile under native mingw !

Congratulations!

> And better yet if I cd into i686-pc-ming32/bin and run octave, it even runs!

Could you run "make check" ?

> 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.

I'd swear that it is in the mxe dependencies - but I must be wrong.

> 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.

Same here. I think I described that in the very first mail in this thread.

> 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.

It might be due to confusion between mingw paths starting from
./mingw/msys/1.0/home/<username>/
and Windows paths that some mingw proggies run into. It seems to be one 
of the common pitfalls of mingw.

> 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)

When I built qt4 a year ago I just entered "qmake release" or something 
simple like that, and it simply built OK - but with some pre- or postfix 
in the .dll names that had to be removed (Michael Goffioul pointed me to 
that, initially I didn't notice).

> 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.

Maybe the mkspecs are copied there into place by the mxe build scripts? 
(wild guess)
I think one can add a "-platform win32-g++" option to configure.exe that 
should (uhm, might) point to the proper mkspecs subdir.

Philip