cross-compile Qt build tools: qmake.exe, rcc.exe...

[starius]

See http://lists.nongnu.org/archive/html/mingw-cross-env-list/2015-10/msg00016.html

I need that when using the cross-compiled libs on windows platform for building other projects. For example, cmake does check for qmake.exe, rcc.exe etc..

[aquiles2k]

Just want to second the need for this feature.

I mostly need this to work with a mxe compiled qt5 (including webkit) on a windows dev machine.

[tonytheodore]

Qt's configure script doesn't seem to have an easy way to separate out the qmake bootstrapping. I imagine the other tools should be easy enough to cross-compile since they use qmake (which is known to work for the rest of Qt).

From comment on host toolchain plugin

Could this be adapted to also build qt host tools like qmake.exe rcc.exe etc. ?

You could try using the host toolchain on a windows machine to configure a minimal qt. The configure step will build qmake.exe and it may be straightforward from there to build just the tools.

[aquiles2k]

Zapping through some code it seems qmake gets built inside the qtbase module which has a seperate configure and produces Makefiles with qmake targets. I'm not very familiar with the internals of cross-compiling unfortunately and if we already do this stuff, excuse my ignorance :) If not, it might be possible to adapt some of this to build a qmake.exe?

[aquiles2k]

Ok, so far this kindof works:

• Building host-toolchain through plugin and copy it to win machine
• Download qt source and place it where u can reach it (i tried it with the whole thing - it will probably also work with just the qtbase module)
• create a batch file to set your path to the toolchain bin and call configure.bat
• qmake.exe gets build - find it in qtbase/bin

I have yet to check if it works with the qt5 version build through mxe - most probably the paths wont fit

[tonytheodore]

See #1431

[aquiles2k]

Cool, i'll test that next week and how it all comes together when using it as a fully functional qt build usable on the host machine.

[tonytheodore]

Ha! I imagine "fully functional" will be the hard part (and this wasn't exactly easy) ;)

[tonytheodore]

Qt test program is working - #1436

[tonytheodore]

qmake is fine with cmd.exe, but cmake and pkg-config are going to need a proper shell. I've added some notes https://github.com/mxe/mxe/tree/master/plugins/examples/host-toolchain#cmake

[aquiles2k]

Hi, finally had time to test this and stumbled upon:

/Users/aj/dev/mxe/usr/bin/i686-w64-mingw32.shared-ld: cannot find -lpthread
collect2: error: ld returned 1 exit status
make[2]: *** [../bin/qmake.exe] Error 1
make[1]: *** [build-only-qt5-host-tools_i686-w64-mingw32.shared] Error 2
real    4m30.727s
user    4m6.602s
sys 0m17.140s
------------------------------------------------------------
[log]      /Users/aj/dev/mxe/log/qt5-host-tools_i686-w64-mingw32.shared

See pastebin (http://pastebin.com/YnhDLKQY)

I find it confusing since i cant see any -lpthread in the linker call.

As a note my settings.mk contains
MXE_GCC_THREADS := posix --disable-sjlj-exceptions --with-dwarf2

[tonytheodore]

I haven't tested with posix/dw2, what's the output of i686-w64-mingw32.shared-g++ -dumpspecs?

[tonytheodore]

I see, qt host tools are built statically but there's no libthread.a to link to. It may have to wait till my next version of #1019.

[aquiles2k]

Dumpspec:

pastebin (http://pastebin.com/Hm4ABWyp)

Anything i can do to help?

[tonytheodore]

See #1479, tested with posix/dw2 on i686-w64-mingw32.shared and Win7 32.

[aquiles2k]

Thanks for the quick fix! I got it compiled now. I could even test it successfully with some of my smaller projects. I just added a new kit in qt creator on my host win dev pc with the built qmake.exe and g++.exe and everything was correctly compiled.

Im doing some more tests but so far - great job :)

[tonytheodore]

Thanks, that's good to hear. Note that building on windows can be incredibly slow, I've never found a reason for this so let us know if you find anything.

[aquiles2k]

Dont know if this related to the slowness or just a misconfiguration myself, i just noticed that the file sizes are way bigger than usual. Some kind of optimization or stripping missing?

Compared to mingw 4.9.2 bundled with Qt binaries
cc1plus.exe 127MB vs 17MB
g++.exe 3.3MB vs 1.7MB
ld.exe 8.4MB vs 1MB

even the libgcc dll 586KB vs 118KB

[aquiles2k]

Sidequestion: What config do i need to add to the gcc_host.mk to get a i686-w64-mingw32.shared-windres.exe compiled. The compiler is complaining thats missing when compiling windows resource files into a qt compiled exe.

my host tools complain:

i686-w64-mingw32.shared-windres -i ..\..\..\..\OSCpc\OSC\config\sysicon.rc -o D:\Dev\Tommy\Builds\OSCpc\d_570_mxe\OSC\tmp\obj\sysicon_res.o --include-dir=./../../../../OSCpc/OSC/config --include-dir=D:/Dev/Tommy/OSCpc/OSC/src -DUNICODE -DDEBUG_BUILD -DDEBUG_LOG -DQT_STRICT_ITERATORS=1 -D__PROFILER_ENABLED__ -D__PROFILER_ENABLED_MAP__ -DQT_ENABLE_QEXPLICITLYSHAREDDATAPOINTER_STATICCAST -DWITH_BREAKPAD -DMINGW -DQT_QML_DEBUG -DQT_WEBKITWIDGETS_LIB -DQT_SVG_LIB -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_SERIALPORT_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN
Makefile.Debug:1620: recipe for target 'D:/Dev/Tommy/Builds/OSCpc/d_570_mxe/OSC/tmp/obj/sysicon_res.o' failed
process_begin: CreateProcess(NULL, i686-w64-mingw32.shared-windres -i ..\..\..\..\OSCpc\OSC\config\sysicon.rc -o D:\Dev\Tommy\Builds\OSCpc\d_570_mxe\OSC\tmp\obj\sysicon_res.o --include-dir=./../../../../OSCpc/OSC/config --include-dir=D:/Dev/Tommy/OSCpc/OSC/src -DUNICODE -DDEBUG_BUILD -DDEBUG_LOG -DQT_STRICT_ITERATORS=1 -D__PROFILER_ENABLED__ -D__PROFILER_ENABLED_MAP__ -DQT_ENABLE_QEXPLICITLYSHAREDDATAPOINTER_STATICCAST -DWITH_BREAKPAD -DMINGW -DQT_QML_DEBUG -DQT_WEBKITWIDGETS_LIB -DQT_SVG_LIB -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_SERIALPORT_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.

[tonytheodore]

Interesting size differences, thanks. I'll have a look.

windres.exe (unprefixed) is installed by binutils-host.

[aquiles2k]

Hm, so i see the qt provided mingw also doesnt provide a prefixed windres.exe just the normal. I then renamed my existing windres.exe into a prefixed one and it seems to have worked. Is there a misconfiguration in gcc or the binutils that he expects a prefixed one?

[tonytheodore]

The qmake specs probably are looking for prefixed ones, try this:

diff --git a/plugins/examples/host-toolchain/binutils-host.mk b/plugins/examples/host-toolchain/binutils-host.mk
index bed45ea..8f096c0 100644
--- a/plugins/examples/host-toolchain/binutils-host.mk
+++ b/plugins/examples/host-toolchain/binutils-host.mk
@@ -19,9 +19,13 @@ define $(PKG)_BUILD
     $(subst --disable-werror,\
             --disable-werror \
             --prefix='$(PREFIX)/$(TARGET)' \
+            --program-prefix='$(TARGET)-' \
             --host='$(TARGET)',\
     $(binutils_BUILD))

+    # install unprefixed versions also
+    $(MAKE) -C '$(1)/binutils' -j 1 install-binPROGRAMS program_transform_name=
+
     # tools seem to be duplicates of '$(PREFIX)/$(TARGET)'
     rm -rf '$(PREFIX)/$(TARGET)/$(TARGET)'
 endef

[tonytheodore]

See #1480. I think it's better to keep using the prefixed versions, eventually I'd rather have no unprefixed ones so multiple variants can be used side-by-side.