I’ve locally tried to test out a gtk4 app migration to core24 (changing core22->core24 and architectures->platforms), and got following messages in console:
libpxbackend-1.0.so: cannot open shared object file: No such file or directory
Failed to load module: /home/yvs/snap/pingpath/common/.cache/gio-modules/libgiolibproxy.so
/usr/share/libdrm/amdgpu.ids: No such file or directory
complains about amdgpu.ids there were always, but “No such” libpxbackend-1.0.so is a new one.
App build with core24 works despite those warnings, but anyway:
Is there something else that need to take into account for core24?
and, is it possible to have builds for core22 and core24 at the same time?
I see these libpxbackend messages on my recently migrated snaps too. I haven’t had time to dig into what these are. I am going to summon @jamesh on that one.
Perhaps @Saviq or @zyga-snapd can provide more insight on the amdgpu.ids issue/warning.
/usr/share/libdrm/amdgpu.ids: No such file or directory
This should be handled by the gpu-2404 interface together with the GNOME extension adding the libdrm layout (actually it should have been for core22 as well):
Can you please post the output of these commands, substituting <snap> with your snap name?
If the first stat works, but the second one does not, that’s a SnapD bug being worked on right now (using layout: over an interface: content’s target:) . Rebooting / reinstalling the snap might help in this case.
Why would you want that? A big reason to use snaps is the fact you can build it once and run across Linux distributions, versions. You don’t need the snap matching the host OS at all.
and, is it possible to have builds for core22 and core24 at the same time?
Why would you want that? A big reason to use snaps is the fact you can build it once and run across Linux distributions, versions. You don’t need the snap matching the host OS at all.
In general because older libs and frameworks are not so big and more likely will correctly work on old hardware.
In the case of core24-gnome46: gnome42(i.e. gtk4.12) uses usual gl by default, since gtk4.14 there’s gles by default and other default renderers ngl or vulkan (forgot which one is in gnome 4.6). So that an app based on core22+gnome42 could be used as a backup (or option) in case of rough edges with core24+gnome46.
p.s. it was just kinda a philosophical question on the way, let’s put it away
I can see the file in the snap as /snap/gnome-46-2404/current/usr/lib/x86_64-linux-gnu/libproxy/libpxbackend-1.0.so, which would not be on the regular library path.
So that allows it to resolve libpxbackend-1.0.so when the library is installed to the location it was built for.
Updating the desktop-launch script to add $SNAP_DESKTOP_RUNTIME/usr/lib/$ARCH/libproxy to LD_LIBRARY_PATH will likely fix the problem. You can probably verify this with your existing snap by calling snap run --shell command, updating LD_LIBRARY_PATH, then manually calling your command from within the sandbox shell.
I am suggesting doing this within the gnome-46-2404 snap itself. This would automatically fix any snaps using the extension (even those built before the fix).
Also, about the amdgpu.ids, maybe we can add this little patch that I’m still waiting for it being merged in upstream, that allows to use an ENV to specify where to find the file. That way we can get rid of the layout: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/273
