Unsolved Cannot compile qmake for win32-g++ (cross compiling)
-
Hello, I'm new in forums same as with qt.
I want to start developing for Raspberry Pi B+ apps written in Qt c++ language. The first problem I was facing is performance of Qt Creator in Raspberry so I decided to try with cross compilation Windows 8.1 -> Raspberry (to code, compile from Windows and remotely debug).I am following that tutorial: http://visualgdb.com/tutorials/raspberry/qt/embedded/
and when I am trying to compile the qmake before generating the toolchain I am getting error:
In function 'DotNET which_dotnet_version(cons QByteArray&)': <path to qtbase>/qmake/generators/win32/msvc_vcproj.cpp:113:43: error: 'KEY_WOW64_32KEY' was not declared in this scope. Error 1
I've tried with both versions: 5.7.0 and 5.6.1 without any luck. I've tried on fresh install of Windows Server 2012 and my home Windows 8.1 both x64 versions, but we're specified exactly that we want to build 32bit versions so why it is trying to deal with WOW64?
I have no idea what to do, I've spent a week to achieve this cross compilation without any luck.
-
Hi and welcome to devnet,
I'd recommend contacting the author of the tutorial. He might likely have hit the same problem as you are.
In any case, I'd recommend considering using a Linux virtual machine. Cross-compiling/debugging from Linux is really easier and you should get up and running faster.
-
Thank you.
I don't think that's problem of the toolchain. I've got other one and currently I am building my own in the cloud. For the other one the same problem occurs.
Tried on: Windows 7 64bit, Windows 8.1 64bit, Windows Server 2012 and Windows Server 2008 with Visual Studio 2013 and .Net Framework 4.5.2 installed.I was taking a look at the code and managed to fix the error from above by changing the KEY_WOW64_32KEY with it's long unsigned int value ( those consts are no longer supported in Windows libraries ). That worked pretty fine.
I am just curious about it's behaviour:
I am specifying to use g++ compiler in platform configuration not mvc one. Why is it building vcproj's and checking for .net versions during the build?After fix I've got another error on libfilesystem, but I have to run the build once again to update this topic with more detailed information.
Wasn't versions mentioned in main post prepared to support win32 cross compile build? Or maybe I am doing something wrong?I've tried to configure qt with commands:
<path to source root>/configure -release -platform win32-g++ -xplatform linux-arm-gnueabi-g++ -opengl es2 -device linux-rasp-pi2-g++ \ -device-option CROSS_COMPILE=C:/SysGCC/Raspberry/bin/arm-linux-gnueabihf- \ -sysroot ~/raspi/sysroot -opensource -confirm-license -make libs \ -prefix /usr/local/qt5
and
<path to source root>/configure -platform win32-g++ -xplatform linux-arm-gnueabi-g++ -release -opengl es2 -device linux-rasp-pi2-g++ -sysroot C:/SysGCC/Raspberry/arm-linux-gnueabihf/sysroot -prefix /usr/local/qt5
while being 'cd' to empty folder.
I am getting compile errors targeting bugs in source code, mainly missing constants.I have Linux version working properly with official Rbpi tool, but in general I am a Windows programmer where I've got everything set up, bought tons of software and configured for my needs, that's why I would like to keep working on Windows OS.
-
What compiling error are you getting ?
-
Sorry for not updating previous post too quickly.
What I've changed currently in source code is I've put that:long KEY_WOW64_64KEY(0x0100); long KEY_WOW64_32KEY(0x0200);
at line 40 on both: MSVC_VCPROJ.H MSVC_NMAKE.cpp
under C:\gnu\setup\qt-everywhere-opensource-src-5.7.0\qtbase\qmake\generators\win32that passed the previous error and failed on:
... In file included from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemmetadata_p.h:54:0, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_p.h:56, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_win.cpp:40: c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/mkspecs/win32-g++/qplatfo rmdefs.h:74:5: note: previous declaration 'EXTENDED_NAME_FORMAT NameDnsDomain' NameDnsDomain = 12 ^ In file included from c:\sysgcc\mingw32\include\security.h:40:0, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_win.cpp:73: c:\sysgcc\mingw32\include\secext.h:26:3: error: conflicting declaration 'typedef enum EXTENDED_NAME_FORMAT EXTENDED_NAME_FORMAT' } EXTENDED_NAME_FORMAT, *PEXTENDED_NAME_FORMAT; ^ In file included from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemmetadata_p.h:54:0, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_p.h:56, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_win.cpp:40: c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/mkspecs/win32-g++/qplatfo rmdefs.h:75:3: error: 'EXTENDED_NAME_FORMAT' has a previous declaration as 'type def enum EXTENDED_NAME_FORMAT EXTENDED_NAME_FORMAT' } EXTENDED_NAME_FORMAT, *PEXTENDED_NAME_FORMAT; ^ In file included from c:\sysgcc\mingw32\include\security.h:40:0, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_win.cpp:73: c:\sysgcc\mingw32\include\secext.h:26:26: error: conflicting declaration 'typede f enum EXTENDED_NAME_FORMAT* PEXTENDED_NAME_FORMAT' } EXTENDED_NAME_FORMAT, *PEXTENDED_NAME_FORMAT; ^ In file included from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemmetadata_p.h:54:0, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_p.h:56, from c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/src /corelib/io/qfilesystemengine_win.cpp:40: c:/gnu/setup/qt-everywhere-opensource-src-5.7.0/qtbase/mkspecs/win32-g++/qplatfo rmdefs.h:75:26: error: 'PEXTENDED_NAME_FORMAT' has a previous declaration as 'ty pedef enum EXTENDED_NAME_FORMAT* PEXTENDED_NAME_FORMAT' } EXTENDED_NAME_FORMAT, *PEXTENDED_NAME_FORMAT; make.exe: *** [qfilesystemengine_win.o] Error 1
And there is more and more of them...
EDIT:
Version 5.0.0 worked fine. What's wrong with the newer ones? -
What version of MinGW are you using ?
Why not use the one provided by Qt which is known to compile the Qt code base ?
-
It is pre-compiled toolchain:
Binutils 2.24
GCC 4.8.1
libc 7.6.1
Package name mingw32-gcc4.8.1.exeI have no idea what are you talking about, there is official mingw for qt? Please help me finding it
EDIT:
IS it this one: https://wiki.qt.io/MinGW ? -
The most simple way is to grab it from the online installer.
-
FYI - I get the exact same error as the OP. I am also attempting the same - cross-compiling on Windows 7 (64-bit) for Raspberry Pi 3.
I was able to cross-compile 5.5.0 just fine and had no issues (besides it taking 18 hours). All the examples work and my co-worker and I even got a nice little I2C example working today.
That said - 5.7.0 is a no-go. First - I got the KEY_WOW64_32KEY error. I tried solving this by changing the function calls to match 5.5.0 by removing the extra argument so it looks like this:
qt_readRegistryKey(HKEY_LOCAL_MACHINE, regKey);
There's 3 function calls, 1 in msvc_vcproj.cpp and 2 in msvc_nmake.cpp
Then those errors disappear and I get the horrendous list of EXTENDED_NAME_FORMAT errors the OP got after defining the KEY_WOW64_32KEY const.
5.7.0 seems to have real issues on Windows...
-
Hi and welcome to devnet,
One thing you can do is bring your question and findings to the interest mailing list. You'll find there Qt's developers/maintainers. This forum is more user oriented.
-
My "fix" (well, to get around the issues) were simply:
in qtbase\mkspecs\win32-g++
in qmake.conf modify QMAKE_CXXFLAGS to read:
"QMAKE_CXXFLAGS = $$QMAKE_CFLAGS -U__STRICT_ANSI__ -D KEY_WOW64_64KEY=0x0100 -DKEY_WOW64_32KEY=0x0200"in qplatformdefs.h disable the definition of EXTENDED_NAME_FORMAT, ie change the #if/#endif wrap
"#if !defined(_WIN32_WINNT) || (_WIN32_WINNT-0 < 0x0500)" to
"#if 0 //!defined(_WIN32_WINNT) || (_WIN32_WINNT-0 < 0x0500)"Not a fix, a fudge, but it allows qmake to build.
Bruce.
-
Great , thank you