Tool definition for linux cross-compilation on windows
-
I hit a strange problem.
While trying to do the cross-compilation for an embedded linux on windows 7 the tool definition in the makefiles are suddenly linux based on a windows system. The result is that the command "test" cannot be found.
A bit of inspection shows that the makefiles contain:
@
first: make_first
QMAKE = C:\Qt\Qt5\5.1.0\Qt5.1.0_Source_Windows\qtbase\bin\qmake
DEL_FILE = rm -f
CHK_DIR_EXISTS= test -d
MKDIR = mkdir -p
COPY = cp -f
COPY_FILE = cp -f
COPY_DIR = cp -f -R
INSTALL_FILE = install -m 644 -p
INSTALL_PROGRAM = install -m 755 -p
INSTALL_DIR = $(COPY_DIR)
DEL_FILE = rm -f
SYMLINK = ln -f -s
DEL_DIR = rmdir
MOVE = mv -f
@Config.cache is
@
-platform
win32-g++
-xplatform
linux-arm-gnueabi-g++-uclinux
-D
QT_NO_CURSOR
-static
-opensource
-no-angle
@The funny thing is that I have been able to obtain the proper tool definition yesterday with the same configuration settings:
@
QMAKE = C:\Qt\Qt5\5.1.0\Qt5.1.0_Source_Windows\qtbase\bin\qmake
DEL_FILE = del
CHK_DIR_EXISTS= if not exist
MKDIR = mkdir
COPY = copy /y
COPY_FILE = $(COPY)
COPY_DIR = xcopy /s /q /y /i
INSTALL_FILE = $(COPY_FILE)
INSTALL_PROGRAM = $(COPY_FILE)
INSTALL_DIR = $(COPY_DIR)
DEL_FILE = del
SYMLINK = copy /y
DEL_DIR = rmdir
MOVE = move
@In both cases the source has been extracted from the same open source .7z archive.
Has anyone an idea why I am hitting this problem?
-
Hi,
Just a wild guess, did you change your console in between ? e.g. msys vs cygwin vs cmd ?
-
Nope.
All is cmd respectively the command under TotalCommander. Started a batch for setting the path. The path was limited to the ruby, python and also the cross-compile tool chain. It must have been the same for both trials. -
Ok…
Then, perhaps you modified the original sources ?
Did you also start the batch today ?
-
Yes, I did always start the batch.
No, the original are not changed only configure was started.I have used .7z because it made the most sense to me since the cross-compile is running on a windows system.
Do you have an idea what to set in the mkspecs section for a cross compile?
I have changed the original arm-linux-gnueabi-g++/qmake.conf to
@qmake configuration for building with arm-uclinuxeabi-g++
MAKEFILE_GENERATOR = MINGW
CONFIG += incremental gdb_dwarf_index
QMAKE_INCREMENTAL_STYLE = sublibinclude(../common/linux.conf)
include(../common/gcc-base-unix.conf)
include(../common/g++-unix.conf)modifications to g++.conf
QMAKE_CC = arm-uclinuxeabi-gcc
QMAKE_CXX = arm-uclinuxeabi-g++
QMAKE_LINK = arm-uclinuxeabi-g++
QMAKE_LINK_SHLIB = arm-uclinuxeabi-g++modifications to linux.conf
QMAKE_AR = arm-uclinuxeabi-ar cqs
QMAKE_OBJCOPY = arm-uclinuxeabi-objcopy
QMAKE_NM = arm-uclinuxeabi-nm -P
QMAKE_STRIP = arm-uclinuxeabi-stripQMAKE_CFLAGS = -pipe -fno-keep-inline-dllexport
QMAKE_CFLAGS = -mthumb -march=armv7 -mfix-cortex-m3-ldrd
QMAKE_CXXFLAGS = -mthumb -march=armv7 -mfix-cortex-m3-ldrdload(qt_config)
@ -
I had the same issue when cross-compiling from windows to linux.
Actually, my fault was that I configured my -xplatform withMAKEFILE_GENERATOR = UNIX
After changing this to = MINGW, everything worked for me.
Maybe this is a bug / unimplemented feature of qmake?? qmake should read the mkspec of the platform specified with "-platform", NOT the "-xplatform" (when it's configured for cross compiling)...!Or am I wrong?
-
[quote author="jseeQt" date="1390468101"]I had the same issue when cross-compiling from windows to linux.
Actually, my fault was that I configured my -xplatform withMAKEFILE_GENERATOR = UNIX
After changing this to = MINGW, everything worked for me.
Maybe this is a bug / unimplemented feature of qmake?? qmake should read the mkspec of the platform specified with "-platform", NOT the "-xplatform" (when it's configured for cross compiling)...!Or am I wrong?[/quote]
I do not know. I was experimenting around. One day I could configure and it compiled so a certain extend. Next I decided to start fresh and simply 7zipped the whole folder and kept. I had copied the mkspecs and also the configure.cache already, so it was more for safety rather than need.The new configure I started with configure.cache and hit all the problem suddenly. I could not and still cannot reproduce the initial case as 7zipped.
The MAKEFILE_GENERATOR does not come from configure. I have added later on just by logic. At least I could get a windows conform makefile.
However, the next problem was the architecture, which was not recognized.
Did you manage the ARM architecture issue and how?
-
Honestly, the configure process with an error message like:
"...ld.exe: could not find ./arch.obj"
when I have "MAKEFILE_GENERATOR=MINGW" in my -xplatform mkspec.
The configure.exe exit then, no Makefiles will be generated.When I change it to "MAKEFILE_GENERATOR = UNIX", then this arch config-test exit with something like:
"'{' is not recognized as a internal or external command".
But the configure.exe do not exit and generates the Makefiles.Very strange, I think at the moment, Qt (more accurate: the configure mechanism) is not ready for Cross-Compiling from Windows -> Linux...
-
OK, thanks for response.
[quote author="jseeQt" date="1390488350"]Honestly, the configure process with an error message like:
"...ld.exe: could not find ./arch.obj"
when I have "MAKEFILE_GENERATOR=MINGW" in my -xplatform mkspec.
The configure.exe exit then, no Makefiles will be generated.
[/quote]
That ios the problem I am hitting too.[quote author="jseeQt" date="1390488350"]
When I change it to "MAKEFILE_GENERATOR = UNIX", then this arch config-test exit with something like:
"'{' is not recognized as a internal or external command".
But the configure.exe do not exit and generates the Makefiles.Very strange, I think at the moment, Qt (more accurate: the configure mechanism) is not ready for Cross-Compiling from Windows -> Linux...[/quote]
In this case it is trying to use linux commands which are not available on Windows. I have installed the Gnu substitutes, but this did not make sense either.I hope to find a solution.
-
Hello again,
I found a solution...apply this changes to your mkspec qmake.conf:
MAKEFILE_GENERATOR = UNIX
QMAKE_PLATFORM = win32
QMAKE_COMPILER = gccinclude(../common/linux.conf)
include(../common/gcc-base-unix.conf)include(../common/g++-unix.conf)
-
oh, it should be:
#include(../common/g++-unix.conf) -
Look into my "qmake.conf":https://github.com/mariuszekpl/qt52-cross-compile-tegra2-windows-scripts/blob/master/try_0003/qmake.conf
and "03_configure.bat":https://github.com/mariuszekpl/qt52-cross-compile-tegra2-windows-scripts/blob/master/try_0003/03_configure.batThis works for me!
Wery strange is this:
*QMAKE_MOVE = dir & move *
I don't now why , but this works*QMAKE_MOVE = move *
Don't work , mingw-32-make can't find move command -
Thanks to JseeQt and marius,maximus for feedback. I will try and report back.
-
I have adopted the complete qmake.conf of marius above. I contains also JseeQt's suggestions.
I certainly needed to adapt the compiler names and also the compiler settings.
Furthermore, I had to change
@
QMAKE_LIBS += -lrt -lpthread
@basically I removed "-ldl" which had resulted in a missing lib error.
I could manage to go through the complete configuration process.
Starting mingw32-make the compilation ran for a while until the subsequent error occurred.@
mingw32-make[2]: Entering directory 'C:/Qt/Qt5/5.1.0/Qt5.1.0_Source_Wnds/qtbase/src/corelib'
arm-uclinuxeabi-g++ -c -pipe -mthumb -march=armv7 -mfix-cortex-m3-ldrd -g -fPIC -std=c++0x -Wall -W -D_REENTRANT -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_
COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DPCRE_HAVE_CONFIG_H -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I....\mkspecs\linux-arm-uclinuxeabi-g++ -I. -I....\inc
lude -I....\include\QtCore -I....\include\QtCore\5.1.1 -I....\include\QtCore\5.1.1\QtCore -Iglobal -I..\3rdparty\pcre -I..\3rdparty\harfbuzz\src -I..\3rdparty\md5 -I..\3rdparty\md4 -I..\3rdparty\sha3 -I.moc\debug_static -o .obj
\debug_static\qlibraryinfo.obj global\qlibraryinfo.cpp
global\qlibraryinfo.cpp: In static member function 'static QString QLibraryInfo::location(QLibraryInfo::LibraryLocation)':
global\qlibraryinfo.cpp:349:20: error: 'QT_CONFIGURE_SETTINGS_PATH' was not declared in this scope
Makefile:10767: recipe for target '.obj\debug_static\qlibraryinfo.obj' failed
mingw32-make[2]: *** [.obj\debug_static\qlibraryinfo.obj] Error 1
mingw32-make[2]: Leaving directory 'C:/Qt/Qt5/5.1.0/Qt5.1.0_Source_Wnds/qtbase/src/corelib'
Makefile:124: recipe for target 'sub-corelib-make_first' failed
mingw32-make[1]: *** [sub-corelib-make_first] Error 2
mingw32-make[1]: Leaving directory 'C:/Qt/Qt5/5.1.0/Qt5.1.0_Source_Wnds/qtbase/src'
makefile:41: recipe for target 'sub-src-make_first' failed
mingw32-make: *** [sub-src-make_first] Error 2C:\Qt\Qt5\5.1.0\Qt5.1.0_Source_Wnds\qtbase>
@Any ideas for solving are welcome
-
I have this same error and have sollution for this.
But forget do "git push" and update on githubPlease look into my 03_configure.bat agine.
After call configure I update few broken files.
@echo QT_CONFIG += xkbcommon-qt >>mkspecs\qconfig.pri
echo static const char qt_configure_settings_path_str[256 + 12] = "qt_stngpath=/usr/local/Qt-5.2.0/etc/xdg"; >>src\corelib\global\qconfig.cpp
echo #define QT_CONFIGURE_SETTINGS_PATH qt_configure_settings_path_str + 12; >>src\corelib\global\qconfig.cpp@
-
In my opinion qtbase\tools\configure
has small BUG@
enum Platforms {
WINDOWS,
WINDOWS_CE,
WINDOWS_RT,
QNX,
BLACKBERRY,
ANDROID
};@configure don't have platform LINUX and default is WINDOWS
thi is BUG line 3871 in configureapp.cpp
@ if ((platform() != WINDOWS) && (platform() != WINDOWS_CE) && (platform() != WINDOWS_RT))
tmpStream << "#define QT_CONFIGURE_SETTINGS_PATH qt_configure_settings_path_str + 12;" << endl;
@ -
[quote author="marius.maximus" date="1391535321"]I have this same error and have sollution for this.
But forget do "git push" and update on githubPlease look into my 03_configure.bat agine.
After call configure I update few broken files.
@echo QT_CONFIG += xkbcommon-qt >>mkspecs\qconfig.pri
echo static const char qt_configure_settings_path_str[256 + 12] = "qt_stngpath=/usr/local/Qt-5.2.0/etc/xdg"; >>src\corelib\global\qconfig.cpp
echo #define QT_CONFIGURE_SETTINGS_PATH qt_configure_settings_path_str + 12; >>src\corelib\global\qconfig.cpp@
[/quote]Trying to understand what you are doing. I am a bit puzzled because this
@
"qt_stngpath=/usr/local/Qt-5.2.0/etc/xdg";
@is a linux path, but we are on windows.
The subsequent post for configureapp.cpp is referring to the same thing.
Now the question comes up where platform relates to. We are on a windows platform but doing a cross-compilation to linux.
I had downloaded the sources as tar.gz because linux is the target.
A final question what is the source archive you used?
.zip or tar.gz ?I had downloaded tar.gz because linux is the target.
-
is a linux path but we are on windows, but it is cross-compilation for linux ;)
I cross compile for my ARM in linux x86 and compare files created in windows and linux. And add missing things ;)
I used ZIP on windows 8.1 and tar.gz on linux x86
In my opinion platform() should look like this :
@int Configure::platform() const
{
const QString qMakeSpec = dictionary.value("QMAKESPEC");
const QString xQMakeSpec = dictionary.value("XQMAKESPEC");if ((xQMakeSpec.startsWith("winphone") || xQMakeSpec.startsWith("winrt"))) return WINDOWS_RT; if ((qMakeSpec.startsWith("wince") || xQMakeSpec.startsWith("wince"))) return WINDOWS_CE; if (xQMakeSpec.contains("qnx")) return QNX; if (xQMakeSpec.contains("blackberry")) return BLACKBERRY; if (xQMakeSpec.contains("android")) return ANDROID;
//////////////////// BEGIN add by marius.maximus //
if (xQMakeSpec.startsWith("linux"))
return LINUX;
//////////////////// END add by marius.maximus //return WINDOWS;
}
@ -
You have a point there. However, it is not logical that this should be missing for longer already. So the concept might be different and not requiring linux explicitly.
You could file a bug report on "JIRA":https://bugreports.qt-project.org/secure/Dashboard.jspa on this.
Did you succeed with the cross-compilation on windows or are still stuck with other problems in between?
-
bq. You have a point there. However, it is not logical that this should be missing for longer already. So the concept might be different and not requiring linux explicitly.
Maybe nobody sent the patch;)
Jira is my favorite bugreports tool I have my own and I'm admin ;)
All works OK , I tessted it on this module
http://www.toradex.com/products/colibri-arm-computer-modules/colibri-t20 It is tegra II
After compile I add it to QtCreateor compile few examples and run it .
It works !