Priority: P4: Low
Affects Version/s: 5.0.0, 5.0.1
Fix Version/s: None
Component/s: Core: Other
In https://bugzilla.redhat.com/show_bug.cgi?id=905863 a bug was reported where one of the maintainers of the s390 and ppc versions of Fedora Linux tried to get Qt5 cross-compiled for the win32 and win64 target.
The point at where the build fails is:
I think I've found the root cause of this failure but I don't know what the most proper way to fix it is.
At the moment the configure script generates a qconfig.h file which describes the features of the compiler of the target platform (in this case for the i686-w64-mingw32 target). In our situation this file contains defines like:
The build failure I mentioned earlier suspects that QT_COMPILER_SUPPORTS_AVX is defined while it shouldn't be. The qsimd_p.h file contains this piece of code:
#if defined(QT_COMPILER_SUPPORTS_AVX) && defined(Q_CC_GNU)
When cross-compiling Qt5 from a x86 (or x86_64) host these features are (by coincidence) also supported by the host compiler (gcc). However, when the host compiler is using a completely different architecture (like ppc and s390) these defines aren't valid.
I suspect that the generated qconfig.h file is used to compile the native tools (qmake/moc/..) while it actually shouldn't rely on its contents.
One possible solution to this would be to have the configure script generate another qconfig.h file which contains the host-specific compiler features (instead of the target-specific compiler features) and have this qconfig.h file used when compiling the native tools.