[Qt-creator] Qtc, qmake and CROSS_COMPILE (was Re: [Qbs] Qt.core.qtBuildVariant is not supported by this Qt installation)

Christian Gagneraud chgans at gmail.com
Thu Oct 5 08:48:29 CEST 2017


On 3 October 2017 at 23:49, Christian Gagneraud <chgans at gmail.com> wrote:
> [cc qt-creator, from qbs mailing list]
>
> On 2 October 2017 at 15:39, Christian Gagneraud <chgans at gmail.com> wrote:
>> I'm using a specific mkspec in my kit (eg,
>> /path/to/Qt/mkspecs/devices/arm-linux-g++), this mkspec sets
>> "CROSS_COMPILE=arm-linux-gnueabi-", but the arm-linux-gnueabi-gcc is
>> not on the PATH.
>> So QtC prints some warning at start-up (and only at startup):
>
> Actually, only when the project is loaded for the first time, what i
> refer to below as 'configure-time'
>
>> Project ERROR: Compiler arm-linux-gnueabi-g++ not found. Check the
>> value of CROSS_COMPILE -device-option
>> Could not read qmake configuration file
>> /.../mkspecs/devices/linux-arm-gnueabi-g++/qmake.conf.
>>
>> But then, i can still build/run OK (since i guess QtC uses the full
>> compiler path via the toolchains settings).
>>
>> The old method was to setup the path *before* running QtC from the
>> command line...

Which is, if i'm not wrong, what yocto still requires to do.

>
> which means that ${CROSS_COMPILE}g++ resolves to a g++ binary in an
> uncontrolled environment (Qtc+qmake integration).
>
> I think Boot2Qt/Yocto got it sorted, but haven't figured it out, i
> haven't build BootToQt for a while.
> The last time was with TI/beagle for fun and on an evalation license,
> second time on an open source license, and now i'm dealing with
> very-custom ARM toolchains/roots, so no Yocto involved.

I found 5 possibilities with CROSS_COMPILE:
- not defined: qmake refuse to work
- set to the compiler prefix without path: it works but requires your
PATH to contains the path to the ${CROSS_COMPILE}gcc
- set to a relative path: doesn't work, CROSS_COMPILE is not a
constant, it is evaluated as it is used, so is $PWD dependent
- set to a fully-hard-coded absolute prefix: always works but is not
relocation friendly (eg; CROSS_COMPILE=/usr/local/my/$triplet-)
- set to a qmake-based variable absolute prefix: works, is relocatable
as long as your qmake is too (and it's not without "manual"
intervention).

I think that yocto still uses the one that requires $PATH.

Boot2Qt uses the intermediate one:
CROSS_COMPILE=$$[QT_HOST_PREFIX]/${sysroot}/${generic-enough-abi}/$triplet-

It's not indexed by google, but can be found in the public git repositories.

The B2Q looks like the best to me.
But only if you bundle your toolchain/sysroot, the way yocto does (and
the way you should do):
- 1 sysroot for the host that contains all "cross" stuff (one
toolchain per gcc target/ABI, one qmake with several device mkspec
(*))
- 1 sysroot per target/machine,  which is "just" your remote device
roots FS, augmented with debug, profiling, dev, extra informations.

(*) Not tested, i'm not sure this is true, yocto/b2q tends to use
"generic" devices, which is a problem if you deliver (or is delivered
with) a Qt build that is specially tuned for your set of
project/products. This does not only includes your tuning SoC/CPU
flags, but as well Qt configuration decisions that affects ABI (eg
qreal={float,double}, ...)

The B2Q approach is fine if you don't mind that your whole
CROSS_COMPILE is under qmake control, which I guess the oe/poky/yocto
guys wont like.

The problem with the oe/poky/yocto guys is that your whole
CROSS_COMPILE is under control of a shell environement file and this
is not QtCreator friendly.
I've ranted about this on the yocto mailing back in 2013, weirdly
enough, the discussion has been, i think, constructive

BTW, Did you know that Yocto still maintains/contains Qt3 and ipaq
kernels? Not kidding, just saw some ipaq patches flying around. For
Qt3 it's because of the LSB, LSB being, like Yocto, a Linux Foundation
project [2]
For the ipaq story i didn't dare to ask, yet... I'm sure the answer is funny!

Chris

[1] https://www.mail-archive.com/yocto@yoctoproject.org/msg15882.html
[2] https://wiki.linuxfoundation.org/lsb/start



More information about the Qt-creator mailing list