symbol lookup error

[sesselastronaut]

I installed the developer Version of gimp with am on an up-to-date Debian Stable. When I run the programm it throws the following error: /tmp/.mount_GNU_Im7K7RAr/usr/bin/gimp-2.99: symbol lookup error: /tmp/.mount_GNU_Im7K7RAr/usr/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0: undefined symbol: gexiv2_metadata_try_get_tag_multiple Any idea what's missing very welcome or is it meant to only run on Ubuntu systems?

[ivan-hc]

I don't know, I also use Debian, also removed the one installed on my system to test the AppImage and... works fine.

Try to run this command from terminal

LD_DEBUG=libs gimp-dev

and look for the missing libraries on your system. The AppRun also uses system libraries (line 5).

[sesselastronaut]

Thanks for the quick reply! I've attached the output of LD_DEBUG=libs gimp-dev gimp-dev-libs-output.txt but can't find anything else in there than the above mentioned plus:

/tmp/.mount_gimp-dF9ZoAY/usr/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0: error: symbol lookup error: undefined symbol: gexiv2_metadata_try_get_tag_multiple (fatal)

Any idea which library might be missing?

[sesselastronaut]

I've been checking in the search path of /usr/lib/x86_64-linux-gnu/ is only libgimpbase-2.0.so.0 available. Strange it throws an error instead of missing library. libgimpbase-3.0 is part of libgimp3.0-dev, seems like on Debian bullseye only libgimp2.0-dev is available atm, so that's probably the problem. Which version of Debian you're on?

[ivan-hc]

I don't really know. This Appimage is based on the previous Ubuntu LTS (Focal, 20.04), so this should work well with with the latest Debian 12 Stable. I use Debian 13 (Testing) and there is not much difference with the latest Stable, being it released a pair of weeks ago.

This is really strange. I'm looking at your log and there seems to be a conflict with the installed libraries... this is a thing I can't reproduce.

[sesselastronaut]

Hm, very strange, I'm planning to upgrade to testing anyway soon but afaik libgimp3.0-dev is only in experimental ... Conflicting libraries are indicated by a (fatal) at the end of the line in the output of LD_DEBUG=libs gimp-dev?

[ivan-hc]

No, wait! I've seen that many errors are related to GTK2 modules.

What if you run

uset GTK_PATH
gimp-dev

in reference to https://github.com/ros2/ros2/issues/1406

[sesselastronaut]

Doesn't seem to make a difference, gimp-dev still returns: /tmp/.mount_gimp-dZMFeVm/usr/bin/gimp-2.99: symbol lookup error: /tmp/.mount_gimp-dZMFeVm/usr/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0: undefined symbol: gexiv2_metadata_try_get_tag_multiple attached the output with unset GTK_PATH unset-GTK_PATH-gimp-dev-libs-output.txt

[ivan-hc]

I don't really know what happens, all I can say is to investigate with LD_DEBUG, this is the documentation https://bnikolic.co.uk/blog/linux-ld-debug.html

What about the stable GINP AppImage? Is it working for you?

[sesselastronaut]

The stable is similar, throwing the following error: /tmp/.mount_gimpA6peTx/usr/bin/gimp-2.10: symbol lookup error: /tmp/.mount_gimpA6peTx/usr/lib/x86_64-linux-gnu/libgimpbase-2.0.so.0: undefined symbol: gexiv2_metadata_try_get_tag_multiple Thanks for the indication to the LD_DEBUG documentation, I guess I wait for my upgrade to Debian 13 when back home at the end of the month to investigate further.

[ivan-hc]

You don't need to upgrade to Testing to made it work, gimp-dev should work with GLIBC2.34 (Ubuntu 20.04+) while gimp stable should work with GLIBC 2.30 (Ubuntu 18.04+). Run the AppImages with LD_DEBUG and read the logs, maybe there is a missing library or package on your system that I already have instead (I have more than 1700 packages on my system, so it's probable).

Also try to extract the AppImage

cd /opt/gimp-dev
./gimp-dev --appimage-extract

and run LDD this way

ldd ./squashfs-root/usr/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0

also

ldd -v ./squashfs-root/usr/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0

for a more detailed list of libraries.

[sesselastronaut]

Thanks a lot for these indications! My GLIBC Version is 2.31-13, and GTK is 3.24.24-4 & 2.24.33-2. I've attached the output of ldd -v ./squashfs-root/usr/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0 >> gimp-dev-libs-output.txt I've no idea though how to identify from these lines potential libraries that could be missing on my system :/

[ivan-hc]

ok, maybe you miss libglib2 on your system

sudo apt install libglib2.0-bin libglib2.0-data

the error: symbol lookup error is refered to some C libraries, and the packages above (with libglib2.0-0) are needed to compile GIMP and other GNOME/GTK+ programs. Are them installed?

PS: GLIBC 2.31-13 means that you're on Debian Oldstable, it should be OK for both the GIMP AppImages I have, also Ubuntu 20.04 has that GLIBC version https://repology.org/project/glibc/versions

If the solution above is not enough, try to install libgimp2.0 to get other system libraries that may be missing, the list of dependences for your version is here https://packages.debian.org/bullseye/libgimp2.0-dev

[sesselastronaut]

Ja indeed, I'm running on a since 2.5 years always upgraded Debian system, that still seem to have some left overs on board... I've had all the indicated packages (libglib2.0-bin libglib2.0-data libglib2.0-dev libgimp2.0 libgimp2.0-dev) already installed, also went through most of the symbol lookup error & they're mostly related to 3.0 versions of packages. At this point I might go for the upgrade & hope this is the cure but for this I feel better to wait until the end of the month when back at home and access to a second computer, just in case ;)

[ivan-hc]

@sesselastronaut to update is not the solution, I said that my AppImages are compatible with Ubuntu 18.04 (Stable) and Ubuntu 20.04 (Dev).

Can you try this step?

cd /opt/gimp-dev
./gimp-dev --appimage-extract

then edit the AppRun (in /opt/gimp-dev/squashfs-root/AppRun) and replace

export LD_LIBRARY_PATH=/lib64:/usr/lib:/lib:/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu/"${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib32/:"${HERE}"/usr/lib64/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${HERE}"/lib32/:"${HERE}"/lib64/:"${LD_LIBRARY_PATH}"

with

export LD_LIBRARY_PATH="${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib32/:"${HERE}"/usr/lib64/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${HERE}"/lib32/:"${HERE}"/lib64/:"${LD_LIBRARY_PATH}"

then run the extracted AppImage this way

/opt/gimp-dev/squashfs-root/AppRun

and let me know if it works for you

[sesselastronaut]

Haa, thanks, this does the trick, like this I can run it :)

[ivan-hc]

well, so I should change the AppRun

[sesselastronaut]

If this is not a big deal and won't affect other systems I would appreciate it!

[ivan-hc]

no, the AppImage works standalone normally, the fact I pointed it to LD_LIBRARY_PATH=/lib64:/usr/lib:/lib:/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu/ is something I left in the past, when I started build it. We don't need this anymore.

[sesselastronaut]

Many thanks for this and also the amazing support!!

[ivan-hc]

Just restarted GH, so the new updated releases will available soon, wait at least an half hour

[ivan-hc]

If this is not a big deal and won't affect other systems I would appreciate it!

Sorry, I have to revert this fix https://github.com/ivan-hc/GIMP-appimage/commit/ac4706366f12d089023f54be6825c46757b59e93

[ivan-hc]

Now I've added an "if" condition in case the command fails, so prior is your kind of system, else we add the system libraries again. This finally fixes the issue.

[sesselastronaut]

Thanks again! Just been checking after running an update and the behaviour so far is still the same, probably takes some time for this to be integrated in the available image.

[sesselastronaut]

Works now :)