Gtk module loading issue using core22/gnome extension

snapcraft
1

Hello everyone,

I’m working on making a snap package for a java swing/fx app. I am using core22 and the gnome extension:

name: autopsy
base: core22
confinement: strict
...
apps:
  autopsy:
    extensions: [gnome]
...

This appears to work fine on xubuntu 22.04, but I’m hitting issues on other OS’s (i.e. Fedora, Mint, Ubuntu 20.04). Specifically:

(java:8048): Gtk-WARNING **: 11:07:39.254: GTK+ module /snap/autopsy/x1/gnome-platform/usr/lib/gtk-3.0/modules/libcanberra-gtk-module.so cannot be loaded.
GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported.

I looked into it a bit, (I did snap try and launched it into sh), and from the snap’s view nothing of consequence is at that gnome-platform path. I also looked at the env vars that were set, and it looks like I have a bunch pointing to $SNAP/gnome-platform that I’m assuming are coming from the gnome extension, but don’t seem to point to much of anything.

For diagnostic purposes, I added this env var change: export GTK_PATH=/snap/gnome-42-2204/120/usr/lib/x86_64-linux-gnu/gtk-3.0:/snap/gnome-42-2204/120/usr/lib/gtk-3.0, pointing the GTK_PATH to where the snap could see it. That seemed to work at least well enough for the GUI to launch, but I don’t think that’s a long term fix.

Is there something I should be doing to configure either my snapcraft.yaml or the gnome extension specifically so that the application launches properly?

2

Thinking about this a little more, I took the advice here and ran something like cat /proc/$pid/maps | awk '{print $6}' | sort | uniq. I noticed that some of the objects libraries listed included some .so files that were some sort of local cache for javafx (i.e. in ~/snap/autopsy/current/.openjfx were three files: libglass.so, libglassgtk3.so, and libprism_sw.so). Is there any ld path scanning that determines if object libraries from referenced snaps are included in the final snap, and in this case, does the gnome extension only link relevant libraries if snapcraft determines that they will be used? I know I get warning messages indicating a certain library isn’t used anywhere in the snap. I wasn’t sure if that impacts the final generated snap.

3

you can use LD_LIBRARY_PATH in the environment stanza of your apps section in snapcraft.yaml to add additional search paths for libs … theoretically the linter run at the end of a snap build should tell you about the missing libs though …

4

One caveat is that, it cannot (currently at least) if those are loaded through dlopen

1 Like
5

One caveat is that, it cannot (currently at least) if those are loaded through dlopen

Thank you both @ogra and @sergiusens, I played around with this a bit and looked at the javafx code and I do believe that is what happening.

EDIT: I forgot to mention that I can influence that path where libraries are loaded, but my suspicion is somehow those java fx libraries are trying to load gtk libraries and somehow, unable to see the gtk libraries in gnome-platform that are added by the gnome extension. With some further debug code, I’m seeing that the gtk libraries are in gnome-platform at least after the snap starts and before the java process runs. So the path is valid, but somehow I’m still getting this error. Is there any good way to diagnose this? I’m guessing this may be intentional, but I tried running LD_DEBUG before running the snap and it’s not giving me too much other than enough to start up the snap.

6

Try to enter the environment and run from withing the context of the snap by running snap run --shell <snap-name>.<app-name> (without .<app-name>if it matches <snap-name>)

You can also use --strace or --gdb instead of --shell

7

Hi @sergiusens and @ogra, Thank you for your thoughts. Your help has got me closer to where I want to be. I ran some LD_DEBUG from within the app, which showed me that the gtk libs were indeed where they were supposed to be but weren’t loading properly. For instance:

     16332:	/snap/autopsy/x2/gnome-platform/usr/lib/gtk-3.0/modules/libcanberra-gtk-module.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal)

Looking a little closer at my LD_DEBUG output, I’m seeing that I have a lot of instances where I’m bringing in a system library, and beyond that, the system library is being chosen over a library that is in the core snap. For instance,

 16229:	find library=libc.so.6 [0]; searching
...tries a few places in my snap, gnome-platform, and /var/lib/snapd/...
 16229: trying file=/lib/x86_64-linux-gnu/libc.so.6

I’ve noticed that the same library is present in the core22 snap. I don’t explicitly reference core22 library paths, but when I do (i.e. LD_LIBRARY_PATH: $LD_LIBRARY_PATH:/snap/core22/current/lib...), I can at least get my GUI application to fundamentally start up.

I guess my two big questions are:

a) Shouldn’t my snap be referencing the core22 snap or is there some sort of path rewriting where /lib/x86_54-linux-gnu is actually in the core22 snap? I’m guessing they are two different things as the behavior is different, but maybe I’m wrong here.

b) Is there something I should add or change about what I’m doing? I have a strictly confined application, and my current LD_LIBRARY_PATH defined for the app in my snapcraft.yaml is $SNAP/usr/local/lib:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH. Beyond that, I don’t see anything I’m defining causing a problem. I’m defining java flags, solr flags, and gstreamer flags (GST_PLUGIN_SYSTEM_PATH and GST_PLUGIN_SCANNER), PATH set to $SNAP/usr/bin:$SNAP/usr/local/bin:$PATH, DISABLE_WAYLAND: 1, and GTK_USE_PORTAL: 1. I’m also doing cleanup at the end of the process similar to gnome recipes and thunderbird.

Thank you once again for all of your help.

8

@sergiusens and @ogra, feel free to disregard my previous and thank you for all of your help. Ultimately, I do believe it was some sort of java/javafx and gtk issue. I think java was having trouble picking between gtk 2 and 3. I found this stackoverflow comment: https://stackoverflow.com/a/22457177, added -Djdk.gtk.version=3 to my java startup, and my most severe issues went away.

2 Likes