package/libxkbcommon: build libxkbregistry when libxml2 is available - #1
Merged
Merged
Conversation
libxkbregistry is the keyboard layout catalogue half of the library. It
parses the XML layout registry and so needs libxml2, which is presumably
why it was disabled unconditionally rather than wired to a dependency.
wine needs it. Its configure.ac requires XKBREGISTRY_LIBS alongside
wayland-client, wayland-scanner, xkbcommon and linux/input.h before it
will build the Wayland driver, and wine.mk passes --with-wayland for any
build with BR2_PACKAGE_WAYLAND - which turns that notice into a hard
error:
checking for wayland-client.h... yes
checking for wl_display_connect in -lwayland-client... yes
checking for wayland-scanner... .../host/bin/wayland-scanner
checking for xkb_context_new in -lxkbcommon... yes
checking for wayland-egl.h... yes
checking for wl_egl_window_create in -lwayland-egl... yes
configure: error: Wayland development files not found, the Wayland
driver won't be supported.
This is an error since --with-wayland was requested.
Every other term of that test passes; only XKBREGISTRY_LIBS is empty, so
wine and wayland together could not be built on any architecture.
Gated on BR2_PACKAGE_LIBXML2 rather than turned on outright, because
meson.build takes dependency('libxml-2.0') unconditionally once
enable-xkbregistry is set, so a target without libxml2 would fail to
configure.
colemancda
added a commit
to MillerTechnologyPeru/swift-linux
that referenced
this pull request
Aug 4, 2026
Picks up MillerTechnologyPeru/buildroot#1, which builds libxkbregistry wherever libxml2 is present. Without it wine's configure fails the XKBREGISTRY_LIBS term of its wayland test and stops the lib32 build, whatever the architecture.
colemancda
added a commit
to MillerTechnologyPeru/swift-linux
that referenced
this pull request
Aug 4, 2026
Picks up MillerTechnologyPeru/buildroot#1, which builds libxkbregistry wherever libxml2 is present. Without it wine's configure fails the XKBREGISTRY_LIBS term of its wayland test and stops the lib32 build, whatever the architecture.
colemancda
pushed a commit
that referenced
this pull request
Sep 2, 2026
Add the option to configure the atf to load the optee-os binary: BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y Without this, everything was still booting, and even though the versal2_plm was loading the optee-os to its runtime location, it was never actually loaded by the atf. With this option enabled, atf is now properly loading optee with the boot log below. NOTICE: BL31: Executing from 0xbbf00000 NOTICE: BL31: Secure code at 0x1800000 NOTICE: BL31: Non secure code at 0x40000000 NOTICE: BL31: v2.14.0(release):custom NOTICE: BL31: Built : 08:41:36, Aug 25 2026 KATs execution completed. In task dispatch loop I/TC: I/TC: Non-secure external DT found I/TC: pl011: device parameters ignored (115200n8) I/TC: Switching console to device: /axi/serial@f1930000 I/TC: OP-TEE version: Unknown_4.9 (gcc version 14.3.0 (Buildroot 2021.11-18033-g83947c7bb6)) #1 Mon Aug 24 08:45:53 UTC 2026 aarch64 I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html I/TC: Primary CPU initializing I/TC: Cluster shift early-configured: 1 (cores per cluster: 2) I/TC: ASU initialization complete I/TC: OP-TEE OS Running on Platform AMD Versal Gen 2 I/TC: ASU ECC: NIST_P192=SW NIST_P224=SW NIST_P256=HW I/TC: ASU ECC: NIST_P384=SW NIST_P521=SW I/TC: ASU RSA driver successfully initialized I/TC: Primary CPU switching to normal world boot Signed-off-by: Neal Frager <neal.frager@amd.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
libxkbregistry is the keyboard layout catalogue half of the library. It parses the XML layout registry and so needs libxml2, which is presumably why it was disabled unconditionally rather than wired to a dependency.
wine needs it.
configure.acrequiresXKBREGISTRY_LIBSalongside wayland-client, wayland-scanner, xkbcommon andlinux/input.hbefore it will build the Wayland driver, andwine.mkpasses--with-waylandfor any build withBR2_PACKAGE_WAYLAND— which turns that notice into a hard error:Every other term of that test passes; only
XKBREGISTRY_LIBSis empty, so wine and wayland together could not be built on any architecture.Gated on
BR2_PACKAGE_LIBXML2rather than turned on outright, becausemeson.buildtakesdependency('libxml-2.0')unconditionally onceenable-xkbregistryis set, so a target without libxml2 would fail to configure.Found by a lib32/i386 build in swift-linux, which reached wine after ~2.5h and stopped there.