Summary: | >=dev-qt/qtgui-5.12 - In file included from painting/qdrawhelper_avx2.cpp:40: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/avx2intrin.h:574:1: error: inlining failed in call to always_inline ‘__m256i _mm256_or_si256(__m256i, __m256i)’: target | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Voltage <hvoltage> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | 1i5t5.duncan, 4nykey, che, chris, email200202, floppym, franklyfrank, gentoo, herrtimson, josef64, leio, leonchik1976, M4rkusXXL, mbucas, mike, nrndda, pelissetto03, perfect007gentleman, phobosk, polynomial-c, realnc, roman, till2.schaefer, wbrana |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=684010 https://bugs.gentoo.org/show_bug.cgi?id=898644 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 679738 | ||
Bug Blocks: | |||
Attachments: |
emerge --info '=dev-qt/qtgui-5.12.0::qt'
build.log Pass -mavx2 instead of -march=core-avx2 backported patch |
Created attachment 557600 [details]
build.log
Same here. cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping : 11 microcode : 0xb6 cpu MHz : 2516.583 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5035.79 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: I fixed it for me with diff --git a/dev-qt/qtgui/qtgui-5.12.9999.ebuild b/dev-qt/qtgui/qtgui-5.12.9999.ebuild index 6f6d4286..dc5cf076 100644 --- a/dev-qt/qtgui/qtgui-5.12.9999.ebuild +++ b/dev-qt/qtgui/qtgui-5.12.9999.ebuild @@ -154,6 +154,9 @@ src_configure() { $(usex gif '' -no-gif) -gui -system-harfbuzz + -disable-avx + -disable-avx2 + -disable-avx512 $(qt_use jpeg libjpeg system) Same here with "AMD FX(tm)-8350 Eight-Core Processor", also without avx2. The problem is in "config.tests/x86_simd/main.cpp", they try to detect avx2 with: #if T(AVX2) attribute_target("avx2") void test_avx2() { _mm256_zeroall(); __m256i a = _mm256_setzero_si256(); __m256i b = _mm256_and_si256(a, a); (void) _mm256_add_epi8(a, b); } #endif And this tests seems to succeed although AVX2 is not available. To be more precise: The build of the test functions works. But it is never executed within main. When I modify the main to also call the test function, it fails with "Illegal instruction". http://code.qt.io/cgit/qt/qtbase.git/commit/?id=b6cd5fdc6b7c799a80126659f35801af9a26601a "configure: inline openssl test sources" These lines break latest 5.12 live ebuilds because folder config.tests/common is gone: diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass index 83f66220..ce4c3e6e 100644 --- a/eclass/qt5-build.eclass +++ b/eclass/qt5-build.eclass @@ -180,8 +180,8 @@ qt5-build_src_prepare() { # Don't inject -msse/-mavx/... into CXXFLAGS when detecting # compiler support for extended instruction sets (bug 552942) - find config.tests/common -name '*.pro' -type f -execdir \ - sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die + #find config.tests/common -name '*.pro' -type f -execdir \ + # sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die # Don't add -O3 to CXXFLAGS (bug 549140) sed -i -e '/CONFIG\s*+=/ s/optimize_full//' \ (In reply to jospezial from comment #5) > diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass > index 83f66220..ce4c3e6e 100644 > --- a/eclass/qt5-build.eclass > +++ b/eclass/qt5-build.eclass > @@ -180,8 +180,8 @@ qt5-build_src_prepare() { > > # Don't inject -msse/-mavx/... into CXXFLAGS when detecting > # compiler support for extended instruction sets (bug 552942) > - find config.tests/common -name '*.pro' -type f -execdir \ > - sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die > + #find config.tests/common -name '*.pro' -type f -execdir \ > + # sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die > > # Don't add -O3 to CXXFLAGS (bug 549140) > sed -i -e '/CONFIG\s*+=/ s/optimize_full//' \ This seems to have been broken since 2017, 5.9.something [1], where they moved things around... Though if this bug is indeed related to that, it would make me wonder why people were not hitting it earlier than this, and I'm not sure if just refactoring the workaround will fix it. 1. http://code.qt.io/cgit/qt/qtbase.git/commit/config.tests/common?id=f54f7d84 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(-) I hit the same error today. The referenced commit does not fix it for me. (In reply to gerion from comment #8) > I hit the same error today. The referenced commit does not fix it for me. Yeah, it (comment 7) was mainly just to fix building on any system at all. You might try what's mentioned in comment 2, if you didn't yet. Perhaps we'll need some kind of a test that would in required cases do just that. Lamentably, I just hit this on a decrepit AMD Athlon II X2 240. Equally lamentably, I have nothing meaningful to contribute. It is a bit disconcerting that this passed upstream regression tests, but... here we are. 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(-) Please update the summary to qtgui-5.12.1. I had seen this bug but since it only said 5.12, I had hoped it was fixed with 5.12.1. Obviously no such luck. =:^( Similar hardware to Markus but less cores, fx6100. The suggested ebuild patch in comment#2 (modified to omit the -disable-avx bit since I have that) seems to have worked. It just finished merging successfully. =:^) [The live-git plasma-integration-9999 and plasma-workspace-9999 builds from the kde overlay now won't build without qt-12, which of course isn't in the gentoo or kde repos yet, so I had to re-add the qt overlay back to get it. With live and upcoming kdes now requiring qt 5.12 broader use and more bug reports are likely.] This now also affects qtgui-5.12.1 from ::gentoo Doesn't build here either. It seems like the build system should be adding -mavx2 to the compiler command for this file. Is Gentoo doing any patching/sed-ing that might prevent that? First: there are only -march=native problem: -march=native translating to full features list "-march=... -msse ... -mno-avx2 ..." (for example). Most simple & accurate way I found - after configure do: sed -i -e 's:\$(CXXFLAGS) -march=:$(subst -march=native,-mtune=native,$(CXXFLAGS)) -march=:' "${S}"/src/gui/Makefile - there are replacement -march=native to -mtune=native before next -march. Also good idea to add useflag "bindist" & "if !bindist" - unswitch unused features, but I have no free time to explore more. Since there's CPU_FLAGS_X86 in make.conf, perhaps the relevant Qt configure flags should be set accordingly? There's no point building the AVX512-enabled codepaths of Qt on a system that doesn't actually have it. The configure flags are: -sse2, -sse3, -ssse3, -sse4.1, -sse4.2, -avx, -avx2, -avx512 When the relevant instruction set is not listed in CPU_FLAGS_X86, it should be disabled with "-no-". For example -no-avx2 -no-avx512 I believe the software is designed to build support for all cpu variants, and detect the appropriate code to execute at runtime. Disabling instructions at build time is a workaround at best. (In reply to Denis Kaganovich from comment #16) I think you don't understand how -march and -mavx2 interact. The latter always gets moved after the former when gcc invokes cc1, so -mavx2 wins. I have no idea what you are proposing bindist; I suspect you don't understand the purpose of that USE flag. Hmm, it looks like the build is passing -march=native from CXXFLAGS, and then appending -march=core-avx2 from the build system. Possibly those two options do not play well together. (In reply to Mike Gilbert from comment #20) > Hmm, it looks like the build is passing -march=native from CXXFLAGS, and > then appending -march=core-avx2 from the build system. Possibly those two > options do not play well together. Doesn't look like that's the issue. The following builds fine if -march=core-avx2 is used and it doesn't matter if -march=native also appears or not (or where): #include <immintrin.h> int main() { _mm256_set1_epi16(256); } Disregard my previous post. Actually -march=native is exactly the problem the build fails. I used the wrong instruction in my test program. This reproduces the issue: #include <immintrin.h> int main() { __m256i a; _mm256_andnot_si256(a, a); } With just -march=core-avx2 it builds fine. If -march=native is also present, it doesn't. Created attachment 567326 [details, diff]
Pass -mavx2 instead of -march=core-avx2
I think this patch should resolve the build failure.
(In reply to Denis Kaganovich from comment #16) It turns out you were on the right track by pointing out the failure with -march=native. Apologies for my earlier comment. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1488107891b5800d923f2cd45a3ceea693104052 commit 1488107891b5800d923f2cd45a3ceea693104052 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2019-03-02 04:43:36 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2019-03-02 04:43:36 +0000 dev-qt/qtgui: fix build with CXXFLAGS="-march=native" Bug: https://bugs.gentoo.org/672946 Package-Manager: Portage-2.3.59_p2, Repoman-2.3.12_p67 Signed-off-by: Mike Gilbert <floppym@gentoo.org> dev-qt/qtgui/files/qt-5.12-gcc-avx2.patch | 29 +++++++++++++++++++++++++++++ dev-qt/qtgui/qtgui-5.12.1.ebuild | 4 ++++ 2 files changed, 33 insertions(+) I think -mavx2 should be appended so that -march=core-avx2 is kept, because it keeps all the other stuff enabled. core-avx2 enables more than just AVX2, so disabling it might potentially affect code generation. So: -QMAKE_CFLAGS_ARCH_HASWELL = -march=core-avx2 +QMAKE_CFLAGS_ARCH_HASWELL = -march=core-avx2 -mavx2 (In reply to Nikos Chantziaras from comment #26) The source file is composed mainly of compiler intrinsic functions that map to SIMD instructons, so I doubt it makes much difference in reality. I think the build system should only add the the compiler flags it really needs. Forcing the code to be optimized specifically for haswell cores makes no sense. The commit[1] that introduced QMAKE_CFLAGS_ARCH_HASWELL says: "This commit changes the AVX2-optimized code in QtGui to Haswell- optimized instead. That means, for example, that qdrawhelper_avx2.cpp can now use the FMA instructions." So FWIU it's not just AVX2 but all instruction set extensions supported by Haswell (BMI, BMI2, FMA, etc.). Hence the patch doesn't look correct to me. [1] http://code.qt.io/cgit/qt/qtbase.git/commit/?id=c3a4ec5d0bbd5f2710f4fd1d3bd4a2d7f0f507ad Same here with "Intel(R) Core(TM) i7 CPU 950" without avx or avx2 CPU_FLAGS_X86: mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 Thanks @jospezial, your ebuild patch saved my computer. Can we modify the ebuild in the tree with @jospezial workaround until a proper fix is agreed on. Yes, I am try to append -mavx2 after -march=core-avx2 first and it works. But I say "accurate" ;). 1) We (I) don't know why upstream do "-mavx", etc, but single "-march=core-avx2". There can have unknown compatibility reason. 2) -mavx2 make ON avx2, but no underlaying options like -mavx, -msse*. So keep them disabled by "-march=native" can produce some unexpected behaviour. So, I just suggest most agnostic & safe fix, respecting unknown upstream logic. You can test more... if you want. In other solution - don't forget to test "-msse2avx". There are strange option, working on gcc & as. Some of gcc versions, for example, don't pass them to assembler after -march=native, but pass if -avx enabled on cmdline stage (-march and -mavx). If you ready to test everything dark placed on every CPU... ;) PS fyi: -march=native, unlike others, work with special behaviour. gcc is running in 2 stages, first - unroll -march=native into long ("-march=... msse ... -mno-avx2") string and pass to other gcc instance. So, sometimes order & interaction of other options is differ (sometimes fixed later in next gcc versions like "-msse2avx", sometimes there still feature). Also I remember in fact (but not detail) - clang can do some option ordering else (but -march=native in clang is similar to gcc). PPS Anymore, all this features support more then your CPU have, required only if you plan to run code on other hardware, else there are just some overcoding. So, if you want to optionally remove future features, it mean you want something like "binary distribute" your build over various hardware, so IMHO "bindist" looks relevant useflag. But as soon no enthusiasts to this work - no question, I make same on gt4 times ago, but as soon all differs and on first try - compilation breaks - I will not use more time on this... (In reply to Davide Pesavento from comment #28) > The commit[1] that introduced QMAKE_CFLAGS_ARCH_HASWELL says: > > "This commit changes the AVX2-optimized code in QtGui to Haswell- > optimized instead. That means, for example, that qdrawhelper_avx2.cpp > can now use the FMA instructions." The source file can be compiled with -mavx2 without any -march setting. That tells me that the code does require the "FMA instructions", and this is an optional optimization that only affects compiler-generated code. If the code is updated to use other compiler intrinsics that require other instruction sets, the appropriate -mXXX flags must also be added. > So FWIU it's not just AVX2 but all instruction set extensions supported by Haswell (BMI, BMI2, FMA, etc.). Hence the patch doesn't look correct to me. The patch makes the code compile, so it is correct in that regard. It better respects the user's CXXFLAGS, and that's a good thing in my opinion. It might not be exactly what upstream intends, but their intention broke with -march=native. (In reply to Mike Gilbert from comment #34) > The source file can be compiled with -mavx2 without any -march setting. That > tells me that the code does require the "FMA instructions" This should read "the code does NOT require...". Upstream bug: https://bugreports.qt.io/browse/QTBUG-71564 They say it's a GCC bug. Qt has absolutely NO business overriding our -march= choice. End of story imho and this GCC bug is a good thing to weed out upstreams that mess with it, so to say. The gcc bug was fixed upstream in GCC trunk: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=269164 "Author: hjl Date: Sat Feb 23 19:39:35 2019 UTC (6 days, 23 hours ago) Changed paths: 8 Log Message: driver: Also prune joined switches with negation When -march=native is passed to host_detect_local_cpu to the backend, it overrides all command lines after it. That means $ gcc -march=native -march=skylake-avx512 is the treated as $ gcc -march=skylake-avx512 -march=native Prune joined switches with Negative and RejectNegative to allow -march=skylake-avx512 to override previous -march=native on command-line. gcc/ PR driver/69471 * opts-common.c (prune_options): Also prune joined switches with Negative and RejectNegative. * config/i386/i386.opt (march=): Add Negative(march=). (mtune=): Add Negative(mtune=). * doc/options.texi: Document Negative used together with Joined and RejectNegative. gcc/testsuite/ PR driver/69471 * gcc.dg/pr69471-1.c: New test. * gcc.dg/pr69471-2.c: Likewise. * gcc.target/i386/pr69471-3.c: Likewise. " +1 for qt and others not overriding my -march=native setting. (In reply to Mike Gilbert from comment #34) > (In reply to Davide Pesavento from comment #28) > > The commit[1] that introduced QMAKE_CFLAGS_ARCH_HASWELL says: > > > > "This commit changes the AVX2-optimized code in QtGui to Haswell- > > optimized instead. That means, for example, that qdrawhelper_avx2.cpp > > can now use the FMA instructions." > > The source file can be compiled with -mavx2 without any -march setting. That > tells me that the code does require the "FMA instructions", and this is an > optional optimization that only affects compiler-generated code. It may be using only AVX2 at the moment, but upstream clearly intends to use BMI and FMA in the future. > If the code is updated to use other compiler intrinsics that require other > instruction sets, the appropriate -mXXX flags must also be added. Yes, that's what I meant with my comment. -mavx2 isn't (or won't be) sufficient. (In reply to Mart Raudsepp from comment #38) > Qt has absolutely NO business overriding our -march= choice. End of story > imho and this GCC bug is a good thing to weed out upstreams that mess with > it, so to say. Agreed. Upstream should list all the required -mavx, -mbmi, ... flags for the instruction sets used in the code, rather than setting a specific -march=. The GCC patch (comment 39) applies cleanly on GCC 8.3 and Qt compiles without problems. I put the following 2 patches in /etc/portage/patches/sys-devel/gcc: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.opt?view=patch&r1=269164&r2=269163&pathrev=269164 and https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/opts-common.c?view=patch&r1=269164&r2=269163&pathrev=269164 I probably hit this one as well some time ago, avx2 related (https://bugreports.qt.io/browse/QTBUG-71564). But there was a way to bypass this by specifiyng cpu_flags_x86 in the ebuild, like this for example: --- qtgui-5.12.1-r1.ebuild +++ qtgui-5.12.1-r1.ebuild @@ -15,6 +15,19 @@ IUSE="accessibility dbus egl eglfs evdev +gif gles2 ibus jpeg +libinput +png tslib tuio +udev vnc +xcb" +IUSE_CPU_FLAGS=( +sse2 +sse3 +ssse3 +sse4_1 +sse4_2 +avx +avx2 +avx512 +) +IUSE+=" +${IUSE_CPU_FLAGS[@]/#/cpu_flags_x86_} +" REQUIRED_USE=" || ( eglfs xcb ) accessibility? ( dbus xcb ) @@ -172,5 +185,9 @@ if use libinput || use xcb; then myconf+=( -xkbcommon ) fi + local _f + for _f in ${IUSE_CPU_FLAGS[@]}; do + myconf+=( $(qt_use cpu_flags_x86_${_f} ${_f/_/.}) ) + done qt5-build_src_configure } Adding cpu_flags_x86 is unnecessary with my patch and/or the gcc bug fix. why qt 5.12 isn't masked? (In reply to Mike Gilbert from comment #44) > Adding cpu_flags_x86 is unnecessary with my patch and/or the gcc bug fix. Ok, but if cpu_flags were there from the day one, we wouldn't even hit this one. A more general approach, so we won't hit possible future issues with say avx512 or other CPU instructions unsupported by older hardware. (In reply to wbrana from comment #45) > why qt 5.12 isn't masked? It works for me. I expected opposite. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=28e55a54934fa758aa6af045b61bd8f268a9c11b commit 28e55a54934fa758aa6af045b61bd8f268a9c11b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-03-08 07:50:57 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-03-08 07:50:57 +0000 8.3.0: allow -march=native override with -march=<arch> That fixes build breakage like https://bugs.gentoo.org/672946 where Qt build system uses -march=core-avx2 instead of individual -mavx2 (and friends). Bug: https://bugs.gentoo.org/679738 Bug: https://gcc.gnu.org/PR69471 Bug: https://bugs.gentoo.org/672946 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> 8.3.0/gentoo/26_all_overridable_native.patch | 126 +++++++++++++++++++++++++++ 8.3.0/gentoo/README.history | 3 + 2 files changed, 129 insertions(+) *** Bug 684010 has been marked as a duplicate of this bug. *** This seems to be fixed now in portage tree in dev-qt/qtgui-5.12.3-r1 and dev-qt/qtgui-5.12.4 with the patch qt-5.12-gcc-avx2.patch (which is actually the one proposed here and set as obsolate - https://672946.bugs.gentoo.org/attachment.cgi?id=567326 ) ... Still someone of the Gentoo devs decided to bump to dev-qt/qtgui-5.12.5 (and all QT 5.12.5 BTW) without testing and without adding the patch mentioned above. Thus all QT upgrade fails (breaking whole KDE for example) in situations/hardware as described above (Mine is an AMD with no AVX support) :( For those of you that hit this bug for dev-qt/qtgui-5.12.5, untill they fix the build - please add the patch from portage tree for dev-qt/qtgui-5.12.4 as an user patch in your /etc/portage/patches :) (In reply to PhobosK from comment #50) > This seems to be fixed now in portage tree in dev-qt/qtgui-5.12.3-r1 and > dev-qt/qtgui-5.12.4 with the patch qt-5.12-gcc-avx2.patch (which is actually > the one proposed here and set as obsolate - > https://672946.bugs.gentoo.org/attachment.cgi?id=567326 ) ... > > Still someone of the Gentoo devs decided to bump to dev-qt/qtgui-5.12.5 (and > all QT 5.12.5 BTW) As they should, since bumping just parts of Qt makes no sense (aside from maybe qtwebengine, but that's not really doable right now, and I digress). > without testing Perhaps they don't have the hardware to test it. This is where the "testing" in 'arch' comes very much handy. :] > and without adding the patch mentioned > above. Perhaps there was an issue with it, or it was simply lost in the bump. It happens. I don't remember if we discussed anything regarding this particular patch in recent times... I do forget things, though. > Thus all QT upgrade fails (breaking whole KDE for example) in > situations/hardware as described above (Mine is an AMD with no AVX support) > :( > > For those of you that hit this bug for dev-qt/qtgui-5.12.5, untill they fix > the build - please add the patch from portage tree for dev-qt/qtgui-5.12.4 > as an user patch in your /etc/portage/patches :) Just to confirm, you're saying you fixed things with said patch for you? That would indeed be helpful information. Thanks! (In reply to Chiitoo from comment #51) LOL :) Sorry for my being annoyed above... but lately such "errors" happen too often especially with major packages.... Anyway - > Just to confirm, you're saying you fixed things with said patch for you? > That would indeed be helpful information. > > Thanks! Yes the applied patch for the other 5.12 versions in portage works fine with 5.12.5 ... And all QT GUI + dependents like KDE for example work fine too... As for: > Perhaps they don't have the hardware to test it. This is where the > "testing" in 'arch' comes very much handy. :] True - real hardware testing is the best option but... Perhaps there are some other options like - virtual machines - where one can choose the arch :) Anyway this is not a forum... so I will stop here... Though IMHO the fact remains that when such major packages are bumped even as ~arch they should be thoroughly tested before the submission to portage, 'cause otherwise if they mess up they do it with the whole system :) Thanks The qtgui patch should be unnecessary if you have a recent version of gcc installed. Yeah probably this is true if using GCC 8.3.0 or above... But the 8.3.0 is default (preferred) in Gentoo profile 17.1 and those of us that are still on 17.0 that came with GCC 7.3.0 as default still need the patch :) Or need to set and rebuild with GCC 8.3.0 :) Created attachment 589904 [details, diff]
backported patch
I think you should try to upgrade your gcc and profile, but since this can be very time consuming you might want to try to add the attached patch to your gcc-7.3.0
the ebuild has epatch_user, so it is pulled in when dropped into /etc/portage/patches/sys-devel/gcc-7.3.0
it applies cleanly with patchlevel 1.8, but I haven't actually done any runtime testing with this
it's named gcc-8.3.0-pr69471, since that is where the backport came from
(In reply to PhobosK from comment #54) gcc-8.3.0 work perfectly fine on a 17.0 profile. You should upgrade. Indeed there is no link whatsoever between GCC and profiles. Current ~arch version of GCC is 9.2.0. So thanks very much for testing ~arch Qt 5.12.5 with arch/outdated toolchain, but don't complain that your particular arch/~arch mix wasn't tested beforehand. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a12587ba46aa919fd396195faa5d4ec784c5327 commit 6a12587ba46aa919fd396195faa5d4ec784c5327 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-09-15 16:44:13 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-09-15 16:51:41 +0000 dev-qt/qtgui: Fix build with CXXFLAGS="-march=native" Old fix from 5.12.1 still applies. Reported-by: PhobosK <phobosk@fastmail.fm> Bug: https://bugs.gentoo.org/672946 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtgui/qtgui-5.12.5.ebuild | 2 ++ 1 file changed, 2 insertions(+) *** Bug 699148 has been marked as a duplicate of this bug. *** The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa52bb1b8dedd9db585ea75e70ccbdc3d2bb2791 commit aa52bb1b8dedd9db585ea75e70ccbdc3d2bb2791 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-11-02 12:38:00 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-11-02 15:22:31 +0000 dev-qt/qtgui: Fix build with CXXFLAGS="-march=native" Old fix from 5.12.1 still applies. Bug: https://bugs.gentoo.org/672946 Package-Manager: Portage-2.3.78, Repoman-2.3.17 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtgui/qtgui-5.13.2.ebuild | 2 ++ 1 file changed, 2 insertions(+) *** Bug 703320 has been marked as a duplicate of this bug. *** The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9e38090b509d7e28731583665f91f63793b2f987 commit 9e38090b509d7e28731583665f91f63793b2f987 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-12-18 20:33:37 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-12-18 20:33:37 +0000 dev-qt/qtgui: Fix build with CXXFLAGS="-march=native" Old fix from 5.12.1 still applies. Bug: https://bugs.gentoo.org/672946 Package-Manager: Portage-2.3.78, Repoman-2.3.17 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtgui/qtgui-5.14.0.ebuild | 2 ++ 1 file changed, 2 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=71a6ccc1bcc9b66bbb891365ab17edcd49f7b1c9 commit 71a6ccc1bcc9b66bbb891365ab17edcd49f7b1c9 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-12-25 15:51:30 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-12-25 17:30:33 +0000 dev-qt/qtgui: Sync with Gentoo ebuild repository - Fix build with CXXFLAGS="-march=native" - Block known old users of _populate_Gui_plugin_properties With sufficiently parallelised emerge, if dev-qt/qtgui reverse dependencies are scheduled before modules installing Qt5Gui plugins have been rebuilt, these revdeps will fail cmake after an incompatible change in macro args. - Raise minimum dependency for USE=tslib Bug: https://bugs.gentoo.org/672946 Bug: https://bugs.gentoo.org/703306 Bug: https://bugs.gentoo.org/703336 Package-Manager: Portage-2.3.83, Repoman-2.3.20 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtgui/files/qt-5.12-gcc-avx2.patch | 29 +++++++++++++++++++++++++++++ dev-qt/qtgui/qtgui-5.12.9999.ebuild | 2 ++ dev-qt/qtgui/qtgui-5.14.9999.ebuild | 15 ++++++++++++--- dev-qt/qtgui/qtgui-5.15.9999.ebuild | 15 ++++++++++++--- dev-qt/qtgui/qtgui-5.9999.ebuild | 2 +- 5 files changed, 56 insertions(+), 7 deletions(-) |
Created attachment 557598 [details] emerge --info '=dev-qt/qtgui-5.12.0::qt' I can not build qtgui-5.12 from overlay. The problem is probably the lack of support for the instruction set by my processor (IvyBridge 3210m without avx2).