Appears to fail when trying to link libQtGui, /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.6/src/gui/../../include/QtGui/private/../../../src/gui/painting/qdrawhelper_p.h:396: undefined reference to `qt_memfill32' collect2: error: ld returned 1 exit status Full logs @ https://koji.fedoraproject.org/koji/taskinfo?taskID=8895974
I'll try this recent fix for Qt5: https://qt.gitorious.org/qt/qtbase/commit/9fb4c2c412621b63c06dbbd899f44041b2e126c2
%changelog * Fri Feb 13 2015 Rex Dieter <rdieter> - 1:4.8.6-23 - Qt: FTBFS with gcc5 (#1192464) - Make Adwaita the default theme for applications running in the GNOME DE (#1192453)
Darn, that wasn't enough, was worth a try.
Proposed as a Blocker for 22-alpha by Fedora user rdieter using the blocker tracking app because: Since gcc5 landed, Qt(4) builds fail. We still ship quite a few Qt4 (and KDE4) based applications on the kde spin.
so my initial look, qdrawhelper_p.h references qt_memfill32 alright, and src/gui/painting/qdrawhelper.cpp references a bunch of optimized versions, including: src/gui/painting/qdrawhelper_x86_p.h painting.pri contains too: if(mmx|3dnow|sse|sse2|iwmmxt) { HEADERS += painting/qdrawhelper_x86_p.h \ painting/qdrawhelper_mmx_p.h \ painting/qdrawhelper_sse_p.h \ painting/qdrawingprimitive_sse2_p.h MMX_SOURCES += painting/qdrawhelper_mmx.cpp MMX3DNOW_SOURCES += painting/qdrawhelper_mmx3dnow.cpp SSE3DNOW_SOURCES += painting/qdrawhelper_sse3dnow.cpp SSE_SOURCES += painting/qdrawhelper_sse.cpp SSE2_SOURCES += painting/qdrawhelper_sse2.cpp SSSE3_SOURCES += painting/qdrawhelper_ssse3.cpp IWMMXT_SOURCES += painting/qdrawhelper_iwmmxt.cpp } so it's possible that sse2 (and/or friends) are no longer being detected properly.
build.log contains: Configuration .......... system-sqlite release largefile stl mmx 3dnow sse sse2 sse3 ssse3 sse4_1 sse4_2 avx ... ... MMX/3DNOW/SSE/SSE2/SSE3. yes/yes/yes/yes/yes SSSE3/SSE4.1/SSE4.2..... yes/yes/yes AVX..................... yes So that part looks ok.
Opened, https://bugreports.qt.io/browse/QTBUG-44466
Qt Devs investigated and determined to be a gcc bug, re-assigning. Per QTBUJG-44466 comment: > It's a GCC bug. One file defines a symbol "qt_memfill32" and the other > searches for "_Z12qt_memfill32". > > GCC 4.9, Clang and ICC don't have this problem. Therefore, it's a GCC bug. Reported: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65062 Testcase: template <class> void tf() { extern void (*qt_memfill32)(); qt_memfill32(); } void f() { tf<int>(); }
Restting default assignee(s), see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65062
already dup'd to upstream bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64898 (and fixed upstream) I guess we're just waiting for a fix gcc build downstream