Using a different compiler for Qt projects than the one used to cross-build Qt itself

vikramg

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?

sierdzio

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 :-)

vikramg

I have been able to get this to work by specifying the new compilers in the QMAKE_CC, QMAKE_CXX , and QMAKE_LINK variables. Note, specifying the same compiler binary in QMAKE_LINK is 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++14 does not work. Instead, specify CONFIG += c++14. The former results in the sequence -std=c++14 -std=gnu++11 in 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.6 on 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.6 on the RPi to the compatible library provided with the toolchain tarball (in my case, libstdc++.so.6.0.24).

Anyway, I'm not marking this as solved because this is a hacky solution at best. You couldn't use the .pro file 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.