This is an auto-filled bug because dev-qt/qtwebengine fails to compile on arm. Feel free to adjust the summary to clarify the exact issue. Attached build log and emerge --info
Created attachment 624144 [details] build.log build log and emerge --info
The 'arm_version=n' looks suspicious, and if I'm guessing some things right, that's where the error message is pointing at, too. See also: https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/buildtools/config/linux.pri?h=5.14.1#n60
Accidentally dropped this from the previous comment: What is 'arm_version' set on successful builds of previous versions such as 5.13.2?
Please also test with -march set to the appropriate arch in CFLAGS.
(In reply to Chiitoo from comment #3) > Accidentally dropped this from the previous comment: What is 'arm_version' > set on successful builds of previous versions such as 5.13.2? I got the same result, arm_version=n (In reply to Andreas Sturmlechner from comment #4) > Please also test with -march set to the appropriate arch in CFLAGS. They are added by gcc by default: ~ $ gcc -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -mfloat-abi=hard -mfpu=vfpv3-d16 -mtls-dialect=gnu -marm -march=armv7-a+fp
Please also consider that it is an arm32 chroot on an arm64 hw. I'm chrooting with linux32 command.
@maintainer(s), this is blocking a security bug. Would you be able to spend a few cycles looking into this?
If only few cycles were enough. :] I've spent quite a bunch of them while trying to figure this one out, but so far I don't have anything helpful to share. People in upstream IRC channel have not noticed anything obvious either, and can only guess that "some flags are not passed as QMAKE_CFLAGS" (to whom I am thankful for the input, as always!). Something I might try, is 'grep -r QMAKE_CFLAGS /build-directory/' after configure phase, to see what else is going on in that variable. I don't have too high hopes for it to return anything helpful, but that's what I'd try if I could reproduce the issue. I do wonder if it's a 32-bit specific issue. I've seen something similar [1], though different, that may have been "fixed" by switching to a 64-bit build. 1. https://forums.gentoo.org/viewtopic-t-1100066.html
The other option would be dropping arm.
So, as far as I can see this has no stable revdeps on arm except for dev-python/PyQtWebEngine - which itself has no stable revdeps on arm. In commit 62e2b2ad, this package was arm stabilised without bug reference or citing any revdep. And then later dev-python/PyQtWebEngine was arm stabilised, probably only to align it with dev-qt/qtwebengine or dev-python/PyQt5 keywords. So, while not dismissing this bug, in my opinion this should not hold us back from 5.14.x stabilisation and cleanup old.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9fb143d71dcdcdf31abc464f9b767eae39c98734 commit 9fb143d71dcdcdf31abc464f9b767eae39c98734 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-04-26 13:37:12 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-04-26 18:11:27 +0000 dev-qt/qtwebengine: Drop vulnerable 5.13.2 Effectively dropping package without revdeps back to ~arm. Bug: https://bugs.gentoo.org/713900 Bug: https://bugs.gentoo.org/699328 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtwebengine/Manifest | 1 - .../files/qtwebengine-5.12.5-icu-65.patch | 33 ------ dev-qt/qtwebengine/qtwebengine-5.13.2.ebuild | 126 --------------------- 3 files changed, 160 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f57d4e8fd772ae0c4d972f4fc44ebdc809bc63b9 commit f57d4e8fd772ae0c4d972f4fc44ebdc809bc63b9 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-07-11 11:57:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-07-11 15:20:30 +0000 profiles/arch/arm: don't pull in qtwebengine for Plasma We prefer to just mask it surgically to avoid pulling it on Plasma right now, because it *might* build for users on "real arm" (not just a linux32 chroot on arm64). Bug: https://bugs.gentoo.org/727132 Bug: https://bugs.gentoo.org/713900 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/arm/package.use.mask | 9 +++++++++ 1 file changed, 9 insertions(+)
