Using a different compiler for Qt projects than the one used to cross-build Qt itself
I cross-built Qt for RPi using the official RPi toolchain, which is unfortunately still stuck (as of Oct 2018) at gcc 4.8.3. This old gcc version does not have support for C++14 features. I thought remedying this should be as easy as downloading a new latest-and-greatest toolchain (which I did from the Linaro page) and pointing the C and C++ compilers in my RPi kit in QtCreator to these new binaries.
To my surprise, the build process still uses the old compiler (which I had used to cross-build Qt itself) and fails because it does not recognize C++14 constructs. The new settings for compiler paths in the kit are completely ignored. As long as the EABI is the same, why should it matter what compiler was used to build the Qt libraries vs what compiler is being used to build Qt applications? And if it doesn't, how can I configure application project builds to use a newer compiler?
For normal compilation (not cross compilation) such compiler switching definitely works. You can even use clang with Qt compiled under GCC.
One thing you may take a look at is the Qt's mkspecs - perhaps if you tweak it and point to your new compiler it would work.
Or (harder) you would have to modify the sysroot so that it includes your new cross compiler.
Or recompile Qt itself using your cross compiler.
If you get it to work, please share your solution, I'm eager to run some more moderns compiler on RPi, too :-)
I have been able to get this to work by specifying the new compilers in the
QMAKE_LINKvariables. Note, specifying the same compiler binary in
QMAKE_LINKis essential; otherwise you get errors like
undefined reference to 'operator delete(void*, unsigned int)'because the link step continues to use the old compiler.
Another gotcha is that
QMAKE_CXXFLAGS += -std=c++14does not work. Instead, specify
CONFIG += c++14. The former results in the sequence
-std=c++14 -std=gnu++11in the compiler options - where, as you can see, the gnu++11 supercedes c++14.
There is one additional thing that may be required:
libstdc++.so.6on the target will likely be pretty old as well. This will result in errors like
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3.9' not found /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
when you try to run the application. These can be fixed by pointing the link
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6on the RPi to the compatible library provided with the toolchain tarball (in my case,
Anyway, I'm not marking this as solved because this is a hacky solution at best. You couldn't use the
.profile as-is to build for a different platform, given the hardcoded compiler paths. The real solution would be to find out why the Kit compiler paths don't work.