How to integrate mkspec into a cross-compilation SDK

fatih.erol

Hello.

In order to prepare an SDK that includes qt tools (qmake, moc, rcc, uic), what would the correct process be?
Here is what I have, and but experience problems with qmake finding the spec_pre.prf, etc.

STAGE I
I have prepared an SDK using crosstool-ng, which could be extracted to different folders. The structure of the SDK content is:

/path/to/sdk/
    toolchain/bin
        i686-xyz-g++ (and other compilers/binutils)
    sysroot (headers and libraries from root filesystem on the target)
        usr/include
        usr/lib

STAGE II
I add a mkspec linux-MYDEVICE-g++ under Qt sources qtbase/mkspecs/devices. What variables shall I set in this mkspec?

CROSS_COMPILE
QMAKE_CC, QMAKE_CXX, ... (compiler, linker, ar, )
QMAKE_CFLAGS, QMAKE_CXXFLAGS => --sysroot=/path/to/sdk/sysroot

Should I change other variables like QMAKE_INCDIR, QT_SYSROOT, QT_HOST_*, etc?

STAGE III
I "configure" and cross-compile qtbase with this spec. What should I set extprefix, hostprefix so that it will cross-compile Qt for my target, but also work within the SDK with relative paths?

cd /path/to/build
/path/to/qt/source/configure 
    -device linux-MYDEVICE-G++ ...
    -prefix /usr
    -extprefix /???/sysroot/usr
    -hostprefix /???/toolchain
make
make INSTALL_ROOT=/path/to/install install

STAGE IV
Copy Qt host tools (qmake, moc, rcc, uic) from /path/to/install to, for example, /path/to/sdk/toolchain/bin/qt5/ under SDK toolchain. Is the path important here due to the qmake configuration?

Copy Qt mkspecs from /path/to/install to, for example, /path/to/sdk/toolchain/. Is the path important here? Should I update variables to avoid absolute paths for sysroot, etc?

STAGE V
Build a sample project. How do I tell qmake where to find the correct mkspec? I think, some variables are built in the qmake executable and cannot be overridden by environment variables, and some can be overridden with environment variables?

cd /path/to/example/build
export PATH=/path/to/sdk/toolchain/bin
# export QMAKE_SPEC ???
/path/to/sdk/toolchain/bin/qt5/qmake -spec linux-MYDEVICE-g++ /path/to/example/source/example.pro
make

fatih.erol

It turns out using qt.conf under the same directory as qmake solves the problem.
It can be used to set the paths properly within the cross-compilation toolchain: Using qt.conf

koahnig

@fatih.erol

AFAIK there is an easier way, when you cross compile Qt on your machine, there you need to setup only the cross-compiled qmake in Qt creator. You can then easily switch between different tool chains (e.g. desktop to enbedded build and back) in creator.

fatih.erol

Thank you.

My development machine has its own Qt installation, with a different version. So, QtCreator works fine with the default Desktop kit. Changing the qmake to the cross-compiled version will possibly confuse it due to the built-in paths for mkspecs, other host tools, etc.

But in order to cross-compile for the target device, not necessarily on QtCreator, how will I tell the cross-compiled qmake where the correct mkspec and tools (moc, rcc, uic) for the target device is?

Which environment variables should I provide before running the cross-compiled qmake?

QMAKESPEC?
QMAKE_MKSPECS?
qmake -spec /path/to/sdk/toolchain/mkspecs/linux-MYDEVICE-g++?

Within qmake.conf, which variables should I set in addition to the cross compilation set-up?
Do I change QT_ variables from Configuring qmake in the environment or qmake.conf?

koahnig

@fatih.erol

The idea with Qt is basically that it is compiled for each machine and you may have different Qt versions with separate qmake versions. AFAIK you basically call the qmake for a specific version and all is already set to compile and link. I am not exactly sure about command line, but certainly for creator.

Typically you have an installation like this for windows:

c:\Qt\5.9.1\mingw53_32\bin\qmake.exe 
c:\Qt\5.9.2\mingw53_32\bin\qmake.exe 
c:\Qt\5.10.1\mingw53_32\bin\qmake.exe

other folders are neglected.
By calling the qmake of 5.10.1 all shall be set for complete compilation. And the same for other installations.

I have a Ubuntu desktop with an installed desktop version of Qt. And I have there also the cross-compiled version (for a beagle bone). Both are used in kits by creator and simply by changing the kit, I can do the compilation for either target.

The only open question is if there are environment changes done when switching between different kits. However, thisyou can find out when checking the compile environments within creator.

fatih.erol

The problem is that absolute paths may leak into the binaries (host tools, or cross-compiled libraries), which is a problem when the SDK is copied to another directory.

Within the mkspecs directory, some paths are used relatively such as include(../common/linux.conf), but some paths are set based on value of extprefix parameter to the configure command, for example, QMAKE_INCDIR_OPENGL = /path/to/sdk/sysroot/usr/include/libdrm in mkspecs/modules/qt_lib_gui_private.pri.

So, I am trying to figure out what the best practices would be for:

setting directory paths in configure parameters such as hostprefix, extprefix
setting directory paths in linux-MYDEVICE-g++/qmake.conf
processing directory paths in the mkspecs generated for the host development system like qt_lib_gui_private.pri
settings environment variables for running qmake on the host development system command line to use the correct mkspec and host tools (moc, rcc, uic)

koahnig

@fatih.erol said in How to integrate mkspec into a cross-compilation SDK:

The problem is that absolute paths may leak into the binaries (host tools, or cross-compiled libraries), which is a problem when the SDK is copied to another directory.

You are right. That is the reason at least for qmake to be able to work IIRC.
However, the question what is the harm, if there is any for the applciation you generating. It has to work independently from your installation on your desktop. If that is the case I am not worried about having a path somewhere which is not used.

Within the mkspecs directory, some paths are used relatively such as include(../common/linux.conf), but some paths are set based on value of extprefix parameter to the configure command, for example, QMAKE_INCDIR_OPENGL = /path/to/sdk/sysroot/usr/include/libdrm in mkspecs/modules/qt_lib_gui_private.pri.

So, I am trying to figure out what the best practices would be for:

setting directory paths in configure parameters such as hostprefix, extprefix

setting directory paths in linux-MYDEVICE-g++/qmake.conf

processing directory paths in the mkspecs generated for the host development system like qt_lib_gui_private.pri

settings environment variables for running qmake on the host development system command line to use the correct mkspec and host tools (moc, rcc, uic)

That is outside of my experience. I tend to go for the "official" ways and try to use as much as possible in the main stream of the use. Otherwise fiddling around with all those settings is a typical way to gain a lot of frustration, but no real work done IMHO.

fatih.erol

Thank you.
Btw, where does qmake save its variables, when you run qmake -set XYZ to alter them?

koahnig

@fatih.erol

AFAIK some are compiled in and others are in the mkspecs conf files.

fatih.erol

It looks like:

some are built in the qmake executable based on -hostprefix, -hostbindir, -hostdatadir, -hostlibdir arguments to configure command. I am not sure how exactly they are derived from these variables. Since a qmake is prepared for building qt itself, and when make install is run. I am not sure the values of these arguments can be set to paths relative to the qmake path (such as ../../path/to/toolchain) in the install directory.
When qmake -set VARIABLE VALUE is run, it sets this value in /path/to/sysconfdir/QtProject.conf, according to -sysconfdir argument to configure command, or ${HOME}/.config/QtProject.conf.
Variables have different values for different environments such as QT_HOST_DATA, QT_HOST_DATA/dev, QT_HOST_DATA/get, QT_HOST_DATA/src. It looks like /get and /src are also effective for overriding them with qmake -set for cross-compilation.

fatih.erol

It turns out using qt.conf under the same directory as qmake solves the problem.
It can be used to set the paths properly within the cross-compilation toolchain: Using qt.conf