Summary: | x11-base/xorg-server-21.1.8 fails to compile on arm | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Serbe <peter> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | arm, matoro_gentoo, peter, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Peter Serbe
2023-04-03 11:04:34 UTC
Please attach a full build log and set the status to UNCONFIRMED. Created attachment 859487 [details]
build.log
sorry, i didn't notice that adding the log failed, as the log was a wee bit too big.
I tried to compile x11-base/xorg-server-21.1.7 on a non-updated raspi, which succeeded. The differences in the build job for ../xorg-server-21.1.x/hw/xfree86/int10/helper_exec.c are small - but they might be a hint. I've got for the working complile: ---------------------------------------------------- -Ihw/xfree86/x86emu ... -D_X86EMU -DNO_SYS_HEADERS -Wno-format-nonliteral ---------------------------------------------------- Whereas for the failing compile I had one, that was missing in the OK-case: ---------------------------------------------------- -D_VM86_LINUX ---------------------------------------------------- I have no clue what triggered the chance. On the machine, where the xorg-server compilation fails, I have three packages installed, that may or may not be related: x11-drivers/xf86-input-libinput-1.2.1 x11-drivers/xf86-video-dummy-0.4.0 x11-libs/libXxf86vm-1.1.5 I compared the failed compile task with the corresponding one from a (ARM) machine, where the compile succeeds. The differences were: In the failed compile I have: "... -Ihw/xfree86/x86emu ... -D_X86EMU -DNO_SYS_HEADERS -Wno-format-nonliteral ..." whereas I read for the successful compile: "... -D_VM86_LINUX ..." Furthermore I read in INT10.HOWTO: "Currently defines are available for vm86-mode under Linux and x86emu. They may be activated by defining _X86EMU or _VM86_LINUX respectively." So I am pretty sure, that the issue is, that on this machine xfree86 does not correctly determine the current platform. After a bit of experimentation I got a successful compile by modifying the xorg-server-ebuild by adding: src_configure() { ... emesonargs+=( -Dint10=x86emu ) ... ) I was not able to find out, how meson derives the configure options - but I still have the impression, that there is an underlying bug rather than (as still possible) configuration error on my side. Your emerge --info has aarch64 for the personality which implies you forgot to run linux32. Confirmed, this goes away with proper setarch. I finally found out, what happened. The RaspberryPi 4 will boot the 64 bit kernel and run the 32 bit Gentoo without any complaint. Everything seems to run fine, it is just, that the Meson build system assumes, that it was invoked in a 64 bit system and it then decides not to add /xfree86/x86emu/libx86emu.a.p to its target list. The fix is to add 'arm_64bit=0' to config.txt in the Raspi /boot directory, as otherwise the 64 bit kernel will load - and an innocent fool like me won't notice at all... So yes, the hint at AARCH64 was very right. But even this did not make me seeing the issue until today. |