Created attachment 235742 [details] poudriere build log When compiling on my RPI4 (arm64) but not on any of my amd64 boxes, I'm seeing these three undefined symbol errors; ld: error: undefined symbol: xf86EnableIO ld: error: undefined symbol: xf86DisableIO ld: error: undefined symbol: xf86OSInitVidMem These started with the cutover from -1.20.14 to -21.1.4.
Also reported during review D35661 and noticed by pkg-fallout@ (but not forwarded to port maintainer). https://portsfallout.com/fallout?maintainer=x11%40FreeBSD.org&env=arm64 doesn't list xorg-server for some reason.
It looks like all the missing symbols can be found in hw/xfree86/os-support/bsd/arm_video.c, which seems to be gated by ARM_VIDEO (hw/xfree86/os-support/bsd/Makefile.am), which seems it should be set by configure's $host_cpu check (arm*). ... and that may be the issue... arm* vs aarch*.
It looks like the old configure code and meson build stuff have drifted. Definitely some arm vs aarch64 differences when comparing host_machine.cpu_family(). It also looks like USE_DEV_IO needs to be defined now, where it didn't need to be defined before except for Intel. We'll see if my patches keep the dependencies happy and ultimately work.
Created attachment 235788 [details] hw/xfree86/os-support/meson.build addendum hook in bsd/arm_video.c code. cpu_family() == 'arm' AND 'aarch64' since it isn't wrapped with a system() == "freebsd" like some other checks are. This should fix the xf86OSInitVidMem issue.
Created attachment 235789 [details] patch-include_meson.build There are unwrapped calls to xf86EnableIO() and xf86DisableIO(). They're gated in the code by USE_DEV_IO, so this patch adds in aarch64 in addition to the existing x86 & x86_64 CPU families.
For what it's worth, these changes are working fine for me. Not too many dependencies on it: xf86-input-keyboard: 1.9.0_5 xf86-input-libinput: 1.2.0_1 xf86-input-mouse: 1.9.3_4 xf86-video-scfb: 0.0.7_1 xorg: 7.7_3 xorg-drivers: 7.7_7 xorg-server: 21.1.4,1 My RPI is using this as a driver for X: x11-drivers/xf86-video-scfb
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=39d767fa0b00ed86b29b388d946f3934d9cd6460 commit 39d767fa0b00ed86b29b388d946f3934d9cd6460 Author: John Kennedy <warlock@phouka.net> AuthorDate: 2022-08-15 13:49:33 +0000 Commit: Mikael Urankar <mikael@FreeBSD.org> CommitDate: 2022-08-15 15:10:00 +0000 x11-servers/xorg-server: Fix build on aarch64 Same fix as https://reviews.freebsd.org/D8465 PR: 265691 Approved by: portmgr (build fix blanket) .../xorg-server/files/patch-hw_xfree86_os-support_meson.build | 11 +++++++---- x11-servers/xorg-server/files/patch-include_meson.build (new) | 11 +++++++++++ 2 files changed, 18 insertions(+), 4 deletions(-)
(In reply to commit-hook from comment #7) FYI for armv7 (via a poudriere bulk in process): FAILED: hw/xfree86/libxorgserver.so . . . ld: error: undefined symbol: xf86EnableIO >>> referenced by xf86Configure.c:621 (../hw/xfree86/common/xf86Configure.c:621) >>> libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a >>> referenced by xf86Events.c:453 (../hw/xfree86/common/xf86Events.c:453) >>> libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a >>> referenced by xf86Init.c:585 (../hw/xfree86/common/xf86Init.c:585) >>> libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a >>> referenced 1 more times ld: error: undefined symbol: xf86DisableIO >>> referenced by xf86Events.c:404 (../hw/xfree86/common/xf86Events.c:404) >>> libxorg_common.a.p/xf86Events.c.o:(xf86VTLeave) in archive hw/xfree86/common/libxorg_common.a cc: error: linker command failed with exit code 1 (use -v to see invocation) This was for /usr/ports/ at: # ~/fbsd-based-on-what-commit.sh -C /usr/portsbranch: main merge-base: 5aec6e4a190d0d6a6f78ce9c5674fd5bf6b4b5d0 merge-base: CommitDate: 2022-08-26 04:22:46 +0000 5aec6e4a190d (HEAD -> main, freebsd/main, freebsd/HEAD) biology/paml: Update to 4.10.5 n592962 (--first-parent --count for merge-base) The same sort of error shows up in the FreeBSD build server logs for armv7, for example: http://ampere3.nyi.freebsd.org/data/130releng-armv7-default/97c2cf505715/logs/errors/xorg-server-21.1.4,1.log (for a build started at Tue Aug 23 08:50:16 UTC 2022)
(In reply to John Kennedy from comment #5) How is this supposed to work? AArch64 doesn't have /dev/io.
The same patch may also be needed for 32 bit arm. Unfortunately I have no way to test this beyond a simple compilation as I do not have an AArch32 device with graphics output hooked up.
(In reply to Robert Clausecker from comment #9) Been a while since I looked at at that. My patch probably made the linker happy at the expense of including unused /dev/io code. A better patch would probably be to properly #ifdef the references that weren't gated by USE_DEV_IO. I had the opinion when they yanked out the old configuration method (upstream) that they only got the stuff working for x86. Seemed like a lot of missing corner cases, but I don't know the xorg internals well enough to differentiate between "oops" and cleanup.
(In reply to John Kennedy from comment #11) It would be great if we could get that fixed before 2022Q4 drops. If you like, I can try and come up with a patch. Has this issue been reported upstream?
I've just run into the problem highlighted here but (as per comment 8 and later) on armv7 and the following relates to armv7. My initial comment: This bug was raised for arm64 and has fixed the issue there. Should the armv7 issue be raised as a different bug? Having looked at hw/xfree86/os-support/bsd/arm_video.c, my initial thought was that Clang defines __arm__, whereas the arm_video.c code is testing for __arm32__ but manually defining __arm32__ means arm_video.c doesn't compile because ExtendedEnabled is undefined (it's "static" in hw/xfree86/os-support/bsd/i386_video.c and hw/xfree86/os-support/linux/lnx_video.c so this suggests that the code has been cut-and-pasted without ever testing it). Looking more closely, arm_video.c provides two implementations of xf86EnableIO() and xf86DisableIO() - one uses /dev/io and the other uses /dev/ttyC0 - neither of which are present on either FreeBSD armv7 or arm64. Adding "or host_machine.cpu_family() == 'arm'" to potch-include_meson.build resulted in a functional xorg server for me.
(In reply to Peter Jeremy from comment #13) Could you add a patch to this PR with the changes that resulted in a working xorg server?
Created attachment 238128 [details] Xorg.0.log from running xorg-server-21.1.4 on the RPI-B (armv6) For xorg-server-21.1.4 I used the following to get it running on armv6: --- ./hw/xfree86/os-support/meson.build.ORIG 2022-10-13 20:47:02.232143000 +0200 +++ ./hw/xfree86/os-support/meson.build 2022-10-14 09:40:22.637509000 +0200 @@ -96,6 +96,7 @@ 'bsd/bsd_VTsw.c', 'bsd/bsd_bell.c', 'bsd/bsd_init.c', + 'misc/SlowBcopy.c', 'shared/pm_noop.c' ] --- ./include/meson.build.ORIG 2022-07-12 15:27:57.000000000 +0200 +++ ./include/meson.build 2022-10-14 10:34:53.835142000 +0200 @@ -377,7 +377,7 @@ xorg_data.set('HAVE_SYS_VT_H', cc.has_header('sys/vt.h') ? '1' : false) if host_machine.system() == 'freebsd' or host_machine.system() == 'dragonfly' - if host_machine.cpu_family() == 'x86' or host_machine.cpu_family() == 'x86_64' + if host_machine.cpu_family() == 'x86' or host_machine.cpu_family() == 'x86_64' or host_machine.cpu_family() == 'arm' or host_machine.cpu_family() == 'aarch64' xorg_data.set('USE_DEV_IO', '1') endif elif host_machine.system() == 'netbsd' I tested this by manually starting the server and then using xsetbg to display a color image. /dev/io is accessed, but since it does not exist the code basically does nothing. The /var/log/Xorg.0.log of that run is attached. -- Martin
^Triage: to submitters: is this still a problem on arm 32-bit?
For armv6 (RPI-B+, see comment 15) this would only be relevant if ports could be built use qemu-user-static (which is now broken). And armv6 is not supported anymore anyway. -- Martin p.s. Some discussion in bug 267346.
^Triage: 64-bit fix committed, 32-bit fix OBE.