[Buildroot] [PATCH 1/1] package/mesa3d-demos: fix build failure on musl

[Buildroot] [PATCH 1/1] package/mesa3d-demos: fix build failure on musl

[Fiona Klute via buildroot]

From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>

Patch has been on upstream main for close to 2 years.

Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
---
 ...kan-wsi-use-unsigned-instead-of-uint.patch | 68 +++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 package/mesa3d-demos/0003-vulkan-wsi-use-unsigned-instead-of-uint.patch

diff --git a/package/mesa3d-demos/0003-vulkan-wsi-use-unsigned-instead-of-uint.patch b/package/mesa3d-demos/0003-vulkan-wsi-use-unsigned-instead-of-uint.patch
new file mode 100644
index 0000000000..160dc9010d
--- /dev/null
+++ b/package/mesa3d-demos/0003-vulkan-wsi-use-unsigned-instead-of-uint.patch
@@ -0,0 +1,68 @@
+From 3f4d5ff34e061f3d47b9cf28bff2fc588d8c5326 Mon Sep 17 00:00:00 2001
+From: psykose <alice@ayaya.dev>
+Date: Thu, 23 Mar 2023 21:18:56 +0000
+Subject: [PATCH] vulkan/wsi: use unsigned instead of uint
+
+uint is not a standard type name and fails to build against musl libc
+
+Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
+Upstream: https://gitlab.freedesktop.org/mesa/demos/-/commit/3f4d5ff34e061f3d47b9cf28bff2fc588d8c5326
+Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
+---
+ src/vulkan/wsi/wayland.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/src/vulkan/wsi/wayland.c b/src/vulkan/wsi/wayland.c
+index 444d2bb81..5958d283a 100644
+--- a/src/vulkan/wsi/wayland.c
++++ b/src/vulkan/wsi/wayland.c
+@@ -128,7 +128,7 @@ dispatch_key(xkb_keycode_t xkb_key, enum wl_keyboard_key_state state)
+ }
+ 
+ static void
+-handle_key(uint key, enum wl_keyboard_key_state state)
++handle_key(unsigned key, enum wl_keyboard_key_state state)
+ {
+    xkb_keycode_t xkb_key = key + 8;
+    struct itimerspec timer = {0};
+@@ -151,15 +151,15 @@ handle_key(uint key, enum wl_keyboard_key_state state)
+ }
+ 
+ static void
+-key(void *data, struct wl_keyboard *keyboard, uint serial,
+-    uint time, uint key, enum wl_keyboard_key_state state)
++key(void *data, struct wl_keyboard *keyboard, unsigned serial,
++    unsigned time, unsigned key, enum wl_keyboard_key_state state)
+ {
+    handle_key(key, state);
+ }
+ 
+ static void
+-modifiers(void *data, struct wl_keyboard *keyboard, uint serial,
+-    uint mods_depressed, uint mods_latched, uint mods_locked, uint group)
++modifiers(void *data, struct wl_keyboard *keyboard, unsigned serial,
++    unsigned mods_depressed, unsigned mods_latched, unsigned mods_locked, unsigned group)
+ {
+    xkb_state_update_mask(keyboard_data.xkb_state, mods_depressed, mods_latched,
+                          mods_locked, 0, 0, group);
+@@ -184,7 +184,7 @@ keymap(void *data, struct wl_keyboard *keyboard,
+ }
+ 
+ static void
+-enter(void *data, struct wl_keyboard *keyboard, uint serial,
++enter(void *data, struct wl_keyboard *keyboard, unsigned serial,
+       struct wl_surface *surface, struct wl_array *keys)
+ {
+    uint32_t *key;
+@@ -194,7 +194,7 @@ enter(void *data, struct wl_keyboard *keyboard, uint serial,
+ }
+ 
+ static void
+-leave(void *data, struct wl_keyboard *keyboard, uint serial,
++leave(void *data, struct wl_keyboard *keyboard, unsigned serial,
+       struct wl_surface *surface)
+ {
+    struct itimerspec timer = {0};
+-- 
+GitLab
+
-- 
2.47.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/mesa3d-demos: fix build failure on musl

[Thomas Petazzoni]

Hello Fiona,

On Fri, 24 Jan 2025 13:47:10 +0100
Fiona Klute via buildroot <buildroot@buildroot.org> wrote:

> From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
> 
> Patch has been on upstream main for close to 2 years.
> 
> Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>

Thanks for the fix. Since I don't see any autobuilder failure, do you
have a defconfig that exhibits the issue?

I tried:

BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_BLEEDING_EDGE=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_MESA3D_DEMOS=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_VULKAN_DRIVER_BROADCOM=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
# BR2_TARGET_ROOTFS_TAR is not set

which has a vulkan driver, but it doesn't build the problematic code.

Also, we need to understand since when the problem has been happening
(i.e when the problematic code was added in mesa3d-demos), in order to
be able to backport the fix if needed.

Basically, when fixing an issue, we should never just fix it. We should
always explain since when the problem has started happening.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/mesa3d-demos: fix build failure on musl

[Fiona Klute via buildroot]

Hi Thomas!

Am 05.02.25 um 10:20 schrieb Thomas Petazzoni:
> Hello Fiona,
>
> On Fri, 24 Jan 2025 13:47:10 +0100
> Fiona Klute via buildroot <buildroot@buildroot.org> wrote:
>
>> From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
>>
>> Patch has been on upstream main for close to 2 years.
>>
>> Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
>
> Thanks for the fix. Since I don't see any autobuilder failure, do you
> have a defconfig that exhibits the issue?
>
> I tried:
>
> BR2_arm=y
> BR2_cortex_a9=y
> BR2_ARM_ENABLE_VFP=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_BLEEDING_EDGE=y
> BR2_INIT_NONE=y
> BR2_SYSTEM_BIN_SH_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_MESA3D_DEMOS=y
> BR2_PACKAGE_MESA3D=y
> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y
> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_BROADCOM=y
> BR2_PACKAGE_MESA3D_OPENGL_EGL=y
> BR2_PACKAGE_MESA3D_OPENGL_ES=y
> # BR2_TARGET_ROOTFS_TAR is not set
>
> which has a vulkan driver, but it doesn't build the problematic code.

As far as I remember you need need to build full OpenGL GLX, not just
EGL. This is the related part of my defconfig:

BR2_PACKAGE_CAGE=y
BR2_PACKAGE_MESA3D_DEMOS=y
BR2_PACKAGE_LIBGLVND=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_LLVM=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_V3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ZINK=y
BR2_PACKAGE_MESA3D_VULKAN_DRIVER_BROADCOM=y
BR2_PACKAGE_MESA3D_VULKAN_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_OSMESA_GALLIUM=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XKEYBOARD_CONFIG=y
BR2_PACKAGE_LIBDECOR=y
BR2_PACKAGE_LIBFREEGLUT=y

Note that the X stuff is for libraries required for GLX, it's still a
pure Wayland setup.

> Also, we need to understand since when the problem has been happening
> (i.e when the problematic code was added in mesa3d-demos), in order to
> be able to backport the fix if needed.
>
> Basically, when fixing an issue, we should never just fix it. We should
> always explain since when the problem has started happening.
The "uint" use was introduced here:

https://gitlab.freedesktop.org/mesa/demos/-/commit/813ebef7671f0e54d1b55be9e15ae5586b2b9eb1
https://gitlab.freedesktop.org/mesa/demos/-/commit/5aaa7faeb4de9497535738830e6ebb8f10071877

The first and so far only mesa3d-demos release that contains those
commits is 9.0.0 from March 2023. Considering that was added to
Buildroot in early July 2023 (commit
80304d9911f34f8a0173a4f37d52f93177478cc7) it's probably safe to assume
it's in all still supported releases.

That said, making "since when" a strict requirement for accepting a fix
seems problematic to me, because it might discourage people from
participating. In my situation (getting paid to make things work,
including upstreaming) it's a perfectly reasonable request. But people
who send a patch here and there from hobby coding might feel their
contributions aren't valued, and someone who has a manager breathing
down their neck and complaining about time wasted might decide it's not
worth the trouble. In case of doubt having a fix on the development
branch (and backporting if someone bumps into the problem on a release)
seems preferable over not having it at all. ;-)

Best regards,
Fiona

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/mesa3d-demos: fix build failure on musl

[Thomas Petazzoni]

Hello Fiona,

On Wed, 5 Feb 2025 13:59:14 +0100
Fiona Klute <fiona.klute@gmx.de> wrote:

> As far as I remember you need need to build full OpenGL GLX, not just
> EGL. This is the related part of my defconfig:
> 
> BR2_PACKAGE_CAGE=y
> BR2_PACKAGE_MESA3D_DEMOS=y
> BR2_PACKAGE_LIBGLVND=y
> BR2_PACKAGE_MESA3D=y
> BR2_PACKAGE_MESA3D_LLVM=y
> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_V3D=y
> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ZINK=y
> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_BROADCOM=y
> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_SWRAST=y
> BR2_PACKAGE_MESA3D_OSMESA_GALLIUM=y
> BR2_PACKAGE_MESA3D_OPENGL_GLX=y
> BR2_PACKAGE_MESA3D_OPENGL_ES=y
> BR2_PACKAGE_XORG7=y
> BR2_PACKAGE_XKEYBOARD_CONFIG=y
> BR2_PACKAGE_LIBDECOR=y
> BR2_PACKAGE_LIBFREEGLUT=y

ACK, I'll give it a try.

> Note that the X stuff is for libraries required for GLX, it's still a
> pure Wayland setup.

A pure wayland setup with X is not... really a pure Wayland setup :-)

> > Basically, when fixing an issue, we should never just fix it. We should
> > always explain since when the problem has started happening.  
> The "uint" use was introduced here:
> 
> https://gitlab.freedesktop.org/mesa/demos/-/commit/813ebef7671f0e54d1b55be9e15ae5586b2b9eb1
> https://gitlab.freedesktop.org/mesa/demos/-/commit/5aaa7faeb4de9497535738830e6ebb8f10071877
> 
> The first and so far only mesa3d-demos release that contains those
> commits is 9.0.0 from March 2023. Considering that was added to
> Buildroot in early July 2023 (commit
> 80304d9911f34f8a0173a4f37d52f93177478cc7) it's probably safe to assume
> it's in all still supported releases.

ACK, thanks for the additional research.

> That said, making "since when" a strict requirement for accepting a fix
> seems problematic to me, because it might discourage people from
> participating. In my situation (getting paid to make things work,
> including upstreaming) it's a perfectly reasonable request. But people
> who send a patch here and there from hobby coding might feel their
> contributions aren't valued, and someone who has a manager breathing
> down their neck and complaining about time wasted might decide it's not
> worth the trouble. In case of doubt having a fix on the development
> branch (and backporting if someone bumps into the problem on a release)
> seems preferable over not having it at all. ;-)

I understand your concern. The issue is that if this effort is not done
by the contributor, then it falls on the Buildroot maintainer who
manages the LTS branch, and (s)he will have to do that on each and
every commit. Clearly, it makes a lot more sense to ask each individual
contributor to do a little bit more effort on their patches rather than
having the LTS maintainer have to do this for 100s of commits that have
to be analyzed to see if they should be backported.

In addition, asking this on contributors also forces them to do a
slightly more in-depth research, which also avoids "bogus" bug fixes
that paper over the problem instead of fixing the real root causes.

Hopefully you will understand those different arguments :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot