qtwidgets failing to build on Athlon XP. CPU detection false reports certain instruction enabled, sse4, avx, avx2 to name a few. Obviously, it's wrong. Compilation stops at 'Illegal instruction' Reproducible: Always Steps to Reproduce: 1. emerge qtwidgets:5 2. notice a build failure 3. Actual Results: .obj/cppwriteiconinitialization.o .obj/cppwriteincludes.o .obj/cppwriteinitialization.o .obj/main.o .obj/uic.o -L/usr/lib -lQt5Core -lpthread [32;01m*[0m Running emake in src/widgets make QT_PLUGIN_PATH=/var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2/plugins LD_LIBRARY_PATH=/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} /var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2/bin/uic dialogs/qfiledialog.ui -o .uic/ui_qfiledialog.h Makefile:1354: recipe for target '.uic/ui_qfiledialog.h' failed make: *** [.uic/ui_qfiledialog.h] Illegal instruction [31;01m*[0m ERROR: dev-qt/qtwidgets-5.4.2 failed (compile phase): [31;01m*[0m emake failed [31;01m*[0m [31;01m*[0m If you need support, post the output of `emerge --info '=dev-qt/qtwidgets-5.4.2'`, [31;01m*[0m the complete build log and the output of `emerge -pqv '=dev-qt/qtwidgets-5.4.2'`. [31;01m*[0m The complete build log is located at '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/temp/environment'. [31;01m*[0m Working directory: '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2/src/widgets' [31;01m*[0m S: '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2' Expected Results: qtwidgets compiled and installed
Created attachment 405592 [details] qtwidgets-5.4.2 failure log
Created attachment 405618 [details] /proc/cpuinfo
Please provide emerge --info.
Created attachment 405720 [details] emerge --info
any particular reason you don't use -march=native?
well, this kind of workaround is a guess game. It is very similar to #447368. It make avx, avx2, sse4 (and others) detected and passed corresponding -mavx, -mavx2, -msse4 flags into compilation.
Can you just answer my question please? (In reply to Oleg from comment #6) > It make avx, avx2, sse4 (and others) detected and passed corresponding > -mavx, -mavx2, -msse4 flags into compilation. Nope, I don't see any -mavx/avx2/sse* while compiling uic in your build log...
Also do the following: $ touch empty.cpp $ g++ -S -fverbose-asm -march=athlon-xp -o athlon.s empty.cpp $ g++ -S -fverbose-asm -march=native -o native.s empty.cpp and attach the resulting athlon.s and native.s files.
(In reply to Davide Pesavento from comment #5) > any particular reason you don't use -march=native? Again, i'm not going to play into guess games. Answer with question does not help to resolve the problem and quite abrasive. If you want me to change march to track the issue, then ask: "Please, change the march to native and try to compile qtwidgets again. Post results. This will help me to track the problem"
I misunderstood your answer (and mentioning bug 447368 didn't help). Actually I still don't understand it. If you're referring to -march=native being a "guess game", then from my experience the compiler has been way more accurate at guessing the various flags for my cpu than me setting a particular -march=... So, to rephrase, what I want to know is what the compiler thinks about your cpu.
Created attachment 405858 [details] athlon
Created attachment 405860 [details] native
Thanks. According to your compiler the difference is in the prfchw and sahf flags. Now add -mno-prfchw and -mno-sahf to your C(XX)FLAGS, and rebuild qtcore and qtwidgets with them.
qtcore passed, qtwidgets roughly the same failure.
Created attachment 405862 [details] qtwidgets-5.4.2(-mno-prfchw -mno-sahf) log
Can you determine where the illegal instruction happens? Hint: build with -ggdb and run the last command (the one that fails) under gdb.
https://bugreports.qt.io/browse/QTBUG-35430 https://bugs.archlinux.org/task/38796 it looks like a related problem.
Attach the build.log for qtcore:5 please.
Created attachment 405906 [details] qtcore-succesful-build.log
There's your problem: the build system adds '-msse2 -mfpmath=sse' to the libQt5Core build.
qt_module.prf: sse2:!contains(QT_CPU_FEATURES.$$QT_ARCH,sse2):!host_build:!if(static:contains(QT_CONFIG, shared)) { # If the compiler supports SSE2, enable it unconditionally in all of Qt shared libraries # (and only the libraries). This is not expected to be a problem because: # - on Windows, sharing of libraries is uncommon # - on Mac OS X, all x86 CPUs already have SSE2 support (we won't even reach here) # - on Linux, the dynamic loader can find the libraries on LIBDIR/sse2/ # The last guarantee does not apply to executables and plugins, so we can't enable for them. QT_CPU_FEATURES.$$QT_ARCH += sse sse2 QMAKE_CFLAGS += $$QMAKE_CFLAGS_SSE2 QMAKE_CXXFLAGS += $$QMAKE_CFLAGS_SSE2 }
Let's see what upstream says...
ok, last comment in that report means it has no solution so far.
yep, upstream rejected the patch stating that this behavior is by design.
I've committed a workaround. https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt5-build.eclass?r1=1.22&r2=1.23 Let me know if it solves your problem (you have to rebuild qtcore after you sync, better if you rebuild all qt5 packages)
it's still failing for qtgui, however it might be a different problem, though sse2 mentioned in build.log
Created attachment 408808 [details] qtgui-5.4.2-r1.log
Attach a full build log please.
Created attachment 408848 [details] build.log
So... qdrawhelper.cpp is built without sse2 (obviously) and therefore includes a non-optimized version of qt_memfill{16,32}. This would be fine, except that qdrawhelper_sse2.cpp is also built, because your CONFIG includes "sse2"[*], but this means that the sse2-optimized versions of qt_memfill{16,32} are also built, leading to the "multiple definition" error at link time. [*] Technically, sse2 in CONFIG means that your compiler supports SSE2, which is true, and simd.prf only checks for that. This is arguably another upstream bug. But instead of trying to fix this one too, after the workaround that I already applied, it's better and easier to properly solve the original problem and send the patch upstream, like I intended to do. That will require some time though.
(In reply to Davide Pesavento from comment #25) > I've committed a workaround. > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt5-build. > eclass?r1=1.22&r2=1.23 > Reverted.
*** Bug 559272 has been marked as a duplicate of this bug. ***
don't understand why this bug still is open. just add -mno-sse2 to your CFLAGS (and CXXFLAGS) before compiling any qt:5 stuff and configure will automatically be set up without sse2. IMHO the solution is to check the CPU_FLAGS_X86 environment, and explicitely enable/disable sse2 in the ebuild based on them instead or in addition to parsing CFLAGS. i.e. I see it not as a problem of upstream if CONFIG can be changed accordingly. also, autodetection of sse2 should be done in the ebuild file and not in qt. that's since raw packages are more likely to be cross-compiled for another computer, while ebuild files more often are used for the native system... warning: I just compiled it, didn't try out yet if all sse2 is gone...
(In reply to piotr5 from comment #33) > IMHO the solution is to check the > CPU_FLAGS_X86 environment, and explicitely enable/disable sse2 in the ebuild > based on them instead Is a workaround like this acceptable (I can prepare a patch)? It would be nice to unblock stabilisation.
Sorry for the lack of updates. I've found a much simpler solution that I'd like to try, but which I haven't had time to implement yet. I'll try to do that in the next few days.
*** Bug 568442 has been marked as a duplicate of this bug. ***
I found that adding "-mno-sse2" to my CFLAGS and/or CXXFLAGS solves the problem. Somewhere around line 538 I found the following checks in the qt5-build eclass: # instruction set support $(is-flagq -mno-sse2 && echo -no-sse2) $(is-flagq -mno-sse3 && echo -no-sse3) $(is-flagq -mno-ssse3 && echo -no-ssse3) $(is-flagq -mno-sse4.1 && echo -no-sse4.1) $(is-flagq -mno-sse4.2 && echo -no-sse4.2) A more permanent solution would be to check CPU_FLAGS_X86 (maybe even USE?) for sse2, or at least give a warning if sse2 is missing in that list AND "-mno-sse2" is missing in CFLAGS. That way the user is at least properly educated about CPU_FLAGS_x86 and people wanting to build qt5 on older hardware can do so without too much trouble. @Davide: I'll still test your solution when it comes, in the meantime I'll be using the above 'fix'.
Apparently we also need to account for qtdeclarative when sse2 is missing: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtdeclarative.git/tree/qtdeclarative-opensource-src-5.5.0-no_sse2.patch
I've finally committed a fix https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cd0a7211f461a839bd7ad95571b25924d491138a Please sync your trees in a couple of hours and let me know if it works for you. I tested locally with -march=core2 on an Ivy Bridge CPU and it gives the expected result.
Remember to rebuild qtcore:5 first, then the affected module(s), e.g. qtwidgets.
I've extended the fix to all other arches (well, amd64 in practice) in commit 4508bd5573404563769986101efd36677be05d48, and revbumped qtcore. I'm going to consider this bug fixed. Please reopen if you still have problems.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=bafd5b0b9e0a2678334355ee3547ebf09833749b commit bafd5b0b9e0a2678334355ee3547ebf09833749b Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2018-12-27 20:26:49 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2018-12-27 20:26:49 +0000 qt5-build.eclass: remove obsolete instruction sets workaround This has seemingly been broken since 2017-08-02, where things were moved around [1], and now causes build failures as the directory has been removed completely [2]. 1. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f54f7d84 2. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=73b87697 Bug: https://bugs.gentoo.org/552942 Bug: https://bugs.gentoo.org/672946 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> eclass/qt5-build.eclass | 5 ----- 1 file changed, 5 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35ec5628b90bdc7ad6bb8ccc9e603100ad642cd9 commit 35ec5628b90bdc7ad6bb8ccc9e603100ad642cd9 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2018-12-27 20:26:49 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-02-07 22:08:58 +0000 qt5-build.eclass: remove obsolete instruction sets workaround This has seemingly been broken since 2017-08-02, where things were moved around [1], and now causes build failures as the directory has been removed completely [2]. 1. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f54f7d84 2. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=73b87697 Bug: https://bugs.gentoo.org/552942 Bug: https://bugs.gentoo.org/672946 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/qt5-build.eclass | 5 ----- 1 file changed, 5 deletions(-)
It seems that the revert of the workaround that was reported by Larry the Git Cow reintroduced (one of) the issues it apparently solved. This is discussed in bug #648004, to which a number of (alternative) qt5-build.eclass patches have now been attached.
