| Summary: | dev-qt/qtbase-6.4.2 - src/corelib/global/qsimd_p.h:218:8: error: #error "Please enable all x86 -64-v3 extensions; you probably want to use -march=haswell or -march=x86-64-v3 instead of -mavx2" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tsukasa <mcp_reznor> |
| Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | floppym, ionen |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=898644 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
Emerge -j1 -1 qtbase (without package.env mod) Full Log |
||
Please include the build.log too. (In reply to Tsukasa from comment #0) > Created attachment 870057 [details] > emerge --info > > Same as referenced bug report, What bug? You haven't referenced any. Sorry, thought it went through with the clone of the bug, here you go Bug 898644 Still want to see the *current* build.log please, I want to see how the eclass behaved. Created attachment 870059 [details]
Emerge -j1 -1 qtbase (without package.env mod)
Oh I see, it's because Qt passes -march (for runtime detection code) and re-enables avx2 which then mismatch with the -mno-fma the eclass added. I only tested with "-mno-avx2" which works, but the =native case went untested given I don't have a machine. Not that it can't be fixed, I'll adjust. Does all feel very hacky though. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6dbf85f4b67761b08c539adf4f25a50c96865a52 commit 6dbf85f4b67761b08c539adf4f25a50c96865a52 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-07 22:10:40 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-07 22:16:30 +0000 qt6-build.eclass: more aggressively disable cpu flags mismatch Closes: https://bugs.gentoo.org/913843 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/qt6-build.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Give it some time (~30m) to ensure the change propagates to mirrors, --sync, then please give it another try. Will do, thank you very much for your efforts, didn't expect quite that fast of a response. I LOL'd at the feeling hacky comment. +1 Gold star Created attachment 870061 [details] Full Log From https://github.com/gentoo-mirror/gentoo + f176164da...19bc5bee2 stable sync'd when the patches landed. Worked great! Thanks, good to hear it works. * Adjusting CXXFLAGS for https://bugs.gentoo.org/908420 with: -mno-avx2 -mno-fma Is what I was expecting to see. Just a point of curiosity. CPU_FLAGS_X86: aes avx f16c fma3 fma4 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 xop Any idea why FMA needs diabled? (In reply to Tsukasa from comment #12) > Any idea why FMA needs diabled? Ask Qt, this error comes up when you either have: - avx2 but no fma - no avx2, but do have fma (aka your situation) They (currently) want these to match, either both enabled or both disabled. It's possible may be able to drop the fma matching and just disable avx2 in a future version after [1] though. Albeit [1] will cause it to fail for different people in different ways so it does not allow to remove the workaround entirely. [1] https://bugreports.qt.io/browse/QTBUG-116357 (In reply to Ionen Wolkens from comment #13) > Albeit [1] will cause it to fail * Well, current the proposed fix will rather. https://codereview.qt-project.org/c/qt/qtbase/+/498799 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d863cc9d8ea3722e0ecd6c17e89d88830b45f4fb commit d863cc9d8ea3722e0ecd6c17e89d88830b45f4fb Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-13 12:58:55 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-14 20:39:35 +0000 qt6-build.eclass: skip matching fma in 6.5.3+ Should no longer hard fail if lack AVX2 while have FMA, however it does (still) require to disable AVX2 if lacking anything else for any reason (e.g. broken VMs, oddball hardware, perhaps even users intentionally disabling a feature because they have a problem with it). Generally few users should see their flags modified. Feel the ideal would be for upstream to simply not use features that are disabled rather than error about an incomplete set, or just not use AVX2 if incomplete. Bug: https://bugs.gentoo.org/898644 Bug: https://bugs.gentoo.org/908420 Bug: https://bugs.gentoo.org/913843 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/qt6-build.eclass | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) |
Created attachment 870057 [details] emerge --info Same as referenced bug report, Still not FIXED for AMD FX-8350, I get the same line about using march=haswell etc, I still use a few of these non-pluton/TPM/PSP machines, and I'm sure others are also, Thanks. also, compiling with -march=x86-64-v2 does in fact build correctly.