symbol lookup error: libappstream.so.5: undefined symbol: g_string_free_and_steal

[bandali]

Hi,

Version 0.9.1+git18.g5aae3d9 (current latest/stable) of the appstream-generator snap package from 25 February 2024 fails to run with the following error:

/snap/appstream-generator/165/usr/bin/appstream-generator: symbol lookup error: /snap/appstream-generator/165/usr/lib/x86_64-linux-gnu/libappstream.so.5: undefined symbol: g_string_free_and_steal

This is on an Ubuntu 20.04 LTS host.

[ximion]

Weird, is the Snap running with an older version of GLib than what it was compiled for?

[bandali]

I'm not sure what "it" refers to, but the host is Ubuntu 20.04 as mentioned, and has libglib2.0-0 2.64.6-1~ubuntu20.04.6 installed. This snap has base: core22, so it should have 2.72.4-0ubuntu2.2.

Interestingly, from a quick look at GLib changelogs, it seems g_string_free_and_steal was added in 2.76, which is newer than what's available in either 20.04 or 22.04. Which makes me wonder what's trying to use it on those older versions and why.

[bandali]

@ximion I think I've figured out what's going on: the system glib-d from jammy's repos was built against system glib, which is older and predates the addition of g_string_free_and_steal. However, the gnome-sdk snap ships newer glib (2.78.1, at the moment) which does have that symbol. So, it appears that this newer glib from the gnome-sdk is used during build time, but then the older glib is prioritized for run time (probably via LD_LIBRARY_PATH), resulting in the missing symbol error:

$ echo $LD_LIBRARY_PATH
[...]:/snap/appstream-generator/165/usr/lib/x86_64-linux-gnu:[...]:/snap/appstream-generator/165/gnome-platform/usr/lib/x86_64-linux-gnu:[...]

$ ls -l /snap/appstream-generator/165/usr/lib/x86_64-linux-gnu/libglib*
lrwxrwxrwx 1 root root      23 Jun  8  2023 /snap/appstream-generator/165/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 -> libglib-2.0.so.0.7200.4
-rw-r--r-- 1 root root 1277712 Jun  8  2023 /snap/appstream-generator/165/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4
lrwxrwxrwx 1 root root      21 Dec 10  2021 /snap/appstream-generator/165/usr/lib/x86_64-linux-gnu/libglibd-2.0.so.0 -> libglibd-2.0.so.2.2.0
-rw-r--r-- 1 root root 3078856 Dec 10  2021 /snap/appstream-generator/165/usr/lib/x86_64-linux-gnu/libglibd-2.0.so.2.2.0

$ ls -l /snap/appstream-generator/165/gnome-platform/usr/lib/x86_64-linux-gnu/libglib*
lrwxrwxrwx 1 root root      16 Mar 26 16:48 /snap/appstream-generator/165/gnome-platform/usr/lib/x86_64-linux-gnu/libglib-2.0.so -> libglib-2.0.so.0
lrwxrwxrwx 1 root root      23 Mar 26 16:48 /snap/appstream-generator/165/gnome-platform/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 -> libglib-2.0.so.0.7800.1
-rwxr-xr-x 1 root root 1418664 Mar 26 17:30 /snap/appstream-generator/165/gnome-platform/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.1

So fixing this might be as simple as adjusting LD_LIBRARY_PATH to put gnome-platform's ahead of the other one.

[bandali]

So this issue indeed stems of conflicting glib versions, but per @kenvandine the right course of action is for us to not include glib and instead rely on the one from the gnome snap.

I've opened PR #133 which should fix this.