I have a hunch this looks similar to https://bugs.gentoo.org/908420. Everything build fine when compiling with -march=x86-64 (but it fails with x86-64-v2 too).
Created attachment 894882 [details] emerge.log
Created attachment 894883 [details] build.log
Could you provide the successful build.log for qtbase? It *should* have disabled QT_FEATURE_avx2 and prevented this from being used in qtmultimedia unless I'm missing something. On that note, did you use different *FLAGS for qtbase? Aka maybe you have some old workarounds in package.env? If want to use =native on other dev-qt/*, qtbase needs it as well. Mismatch is not something that can easily support here.
(In reply to Ionen Wolkens from comment #3) > On that note, did you use different *FLAGS for qtbase? Aka maybe you have > some old workarounds in package.env? If want to use =native on other > dev-qt/*, qtbase needs it as well. Mismatch is not something that can easily > support here. (if you did, try to rebuild qtbase with -march=native, then qtmultimedia -- if it works then there's not really anything to do here)
Created attachment 894885 [details] build.log (march=x86-64)
(In reply to Ionen Wolkens from comment #3) > On that note, did you use different *FLAGS for qtbase? Aka maybe you have > some old workarounds in package.env? If want to use =native on other > dev-qt/*, qtbase needs it as well. Mismatch is not something that can easily > support here. I don't have lingering configs in package.env, but qtbase is definitely built with a different -march since it's from Gentoo's binhost (is it -march=x86-64?). However, my system doesn't support AVX2, so it shouldn't be pulled in by =native or am I missing something? x86-64-v2 too, which I also tried and failed.
(In reply to Shiba from comment #6) > I don't have lingering configs in package.env, but qtbase is definitely > built with a different -march since it's from Gentoo's binhost (is it > -march=x86-64?). Oh, binhost.. hadn't considered that. Not quite sure what to do about this at the moment. It would work if you built qtbase yourself with -march=native anyhow. > However, my system doesn't support AVX2, so it shouldn't be > pulled in by =native or am I missing something? x86-64-v2 too, which I also > tried and failed. It's trying to build avx2 bits for runtime detection, but a workaround your cpu gets in the way because it doesn't expect a *FLAGS mismatch.
(In reply to Ionen Wolkens from comment #7) > (In reply to Shiba from comment #6) > > I don't have lingering configs in package.env, but qtbase is definitely > > built with a different -march since it's from Gentoo's binhost (is it > > -march=x86-64?). > Oh, binhost.. hadn't considered that. Not quite sure what to do about this > at the moment. Maybe if could detect this situation and then would have little choice but to filter-out -march=native, but not quite sure how test for this in a simple way. Alternatively could patch qtmultimedia not to rely on -march=haswell and actually pass -mavx2, albeit the issue may surface in other dev-qt/* package and is more of a bandaid.
(have to say it's tempting to just replace =native unconditionally then could remove all these workarounds, albeit given not an issue for most people it'd still be kind of unfortunate)
(In reply to Ionen Wolkens from comment #8) > Maybe if could detect this situation and then would have little choice but > to filter-out -march=native, but not quite sure how test for this in a > simple way. Actually, reading defines in qconfig_p.h may be enough. Not going to look at this now, but it may be manageable.
(In reply to Ionen Wolkens from comment #10) > (In reply to Ionen Wolkens from comment #8) > > Maybe if could detect this situation and then would have little choice but > > to filter-out -march=native, but not quite sure how test for this in a > > simple way. > Actually, reading defines in qconfig_p.h may be enough. Not going to look at > this now, but it may be manageable. Or no, while it'd work this is all getting too hacky and hard to maintain. May use a different approach that detects unusual configurations and just force generic -march only for these.
(In reply to Shiba from comment #0) > I have a hunch this looks similar to https://bugs.gentoo.org/908420. > Everything build fine when compiling with -march=x86-64 (but it fails with > x86-64-v2 too). Did it really fail with -v2? That sounds odd, do you still have the build.log for that one?
(In reply to Ionen Wolkens from comment #12) > (In reply to Shiba from comment #0) > > I have a hunch this looks similar to https://bugs.gentoo.org/908420. > > Everything build fine when compiling with -march=x86-64 (but it fails with > > x86-64-v2 too). > Did it really fail with -v2? That sounds odd, do you still have the > build.log for that one? No wait, nevermind -- I see why it would fail now.
Created attachment 894900 [details] build.log (march=x86-64-v2) Here's the log with x86-64-v2 anyway, just in case. I don't understand much about C/C++ and the likes so I can't directly help, but I can do all the tests you need. It might take me a while though, that PC is tackling py3.12 right now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3373a27c24cd4b06084f8e0ac9fb9d2a695ac214 commit 3373a27c24cd4b06084f8e0ac9fb9d2a695ac214 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-06-02 07:08:01 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-06-02 08:22:07 +0000 qt6-build.eclass: use different workaround for cpu flags issues This also replaces the nasty workaround from qtbase's ebuild on top of the function here. Should "hopefully" be far less error prone, while still allowing -march=native for people who aren't affected. Does mean slightly worse optimizations for those affected, but this still tries to use the highest x86-64-v* and should be insignificant. Tentative, can't fully test without having an affected cpu so may still need work. Closes: https://bugs.gentoo.org/933374 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/qt6-build.eclass | 87 ++++++++++++++++++++++++++++++++----------------- 1 file changed, 58 insertions(+), 29 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b48b3f78072691a3e4170abfd150bdeea065f93 commit 7b48b3f78072691a3e4170abfd150bdeea065f93 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-06-02 07:15:03 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-06-02 08:22:07 +0000 dev-qt/qtbase: remove obsolete cpu feature workaround qt6-build.eclass does a different type of workaround, see the new _qt6-build_sanitize_cpu_flags function. Bug: https://bugs.gentoo.org/933374 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/qtbase-6.7.0-r2.ebuild | 33 +-------------------------------- dev-qt/qtbase/qtbase-6.7.1.ebuild | 33 +-------------------------------- dev-qt/qtbase/qtbase-6.7.9999.ebuild | 33 +-------------------------------- dev-qt/qtbase/qtbase-6.9999.ebuild | 33 +-------------------------------- 4 files changed, 4 insertions(+), 128 deletions(-)
