Dependencies in Distrobox container listed as not found, even though they are installed

Hello there good folks,

I’m a long-time Fedora Silverblue/Kinoite user. Currently I’m trying to run a particular VST under a Distrobox-run Reaper (DAW). Reaper runs fine but this VST (Guitarix.vst) cannot.

When prompting ldd Guitarix.so from inside the container I have the following response:

[username@fedora-toolbox-39 x86_64-linux]$ ldd Guitarix.so 
        linux-vdso.so.1 (0x00007fe1c8e7b000)
        libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fe1c8d9a000)
        libcurl-gnutls.so.4 => /lib64/libcurl-gnutls.so.4 (0x00007fe1c7d79000)
        **libgiomm-2.4.so.1 => not found**
        **libglibmm-2.4.so.1 => not found**
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fe1c8d3a000)
        libsigc-2.0.so.0 => /lib64/libsigc-2.0.so.0 (0x00007fe1c8d30000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fe1c7c2f000)
        **libfftw3f.so.3 => not found**
        libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007fe1c7bb1000)
        **liblilv-0.so.0 => not found**
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fe1c8d2b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe1c8d24000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fe1c7800000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe1c7ad0000)
        libmvec.so.1 => /lib64/libmvec.so.1 (0x00007fe1c7706000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe1c7aab000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe1c7524000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe1c8e7d000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fe1c7a97000)
        libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fe1c7a5e000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fe1c750a000)
        libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007fe1c73fc000)
        libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007fe1c73ee000)
        libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007fe1c73c3000)
        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007fe1c73a1000)
        libnettle.so.8 => /lib64/libnettle.so.8 (0x00007fe1c7349000)
        libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007fe1c7000000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fe1c72f3000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007fe1c72e3000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fe1c7248000)
        libgsm.so.1 => /lib64/libgsm.so.1 (0x00007fe1c7239000)
        libFLAC.so.12 => /lib64/libFLAC.so.12 (0x00007fe1c6f9a000)
        libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007fe1c6f6b000)
        libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x00007fe1c6ec0000)
        libopus.so.0 => /lib64/libopus.so.0 (0x00007fe1c6e64000)
        libogg.so.0 => /lib64/libogg.so.0 (0x00007fe1c6e5a000)
        libmpg123.so.0 => /lib64/libmpg123.so.0 (0x00007fe1c6dfd000)
        libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007fe1c6d85000)
        libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007fe1c6d64000)
        libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007fe1c6d41000)
        libunistring.so.5 => /lib64/libunistring.so.5 (0x00007fe1c6b91000)
        libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007fe1c69ff000)
        libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007fe1c69e9000)
        libhogweed.so.6 => /lib64/libhogweed.so.6 (0x00007fe1c69a6000)
        libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fe1c6901000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fe1c6828000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fe1c6810000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fe1c6809000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fe1c67f9000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fe1c67f2000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fe1c6200000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fe1c67e1000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe1c67b4000)

As you can see, a few depencies are not found. However, when I try yum install [dependencyname] it says the base package is already installed and there’s nothing to do:

[username@fedora-toolbox-39 x86_64-linux]$ sudo yum install liblilv-0.so.0
Last metadata expiration check: 0:24:43 ago on sat, 12 oct 2024 00:16:42 CEST.
Package lilv-libs-0.24.20-1.fc39.i686 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[username@fedora-toolbox-39 x86_64-linux]$ sudo yum install libgiomm-2.4.so.1
Last metadata expiration check: 0:25:38 ago on sat, 12 oct 2024 00:16:42 CEST.
Package glibmm2.4-2.66.7-1.fc39.i686 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

etc.

Note that these weren’t installed before, I installed them with this yum install method. However, even after installing them they appear as not found and thus the Guitarix.vst can’t run.

Any help / hints with this?

OK, I resolved this myself by upgrading the system from within the Distrobox Fedora container from version 39 to 40 by following the following procedure (taken from: Reddit - Dive into anything):

$ sudo dnf update --refresh
$ sudo dnf system-upgrade download --releasever=40
$ sudo dnf system-upgrade reboot
# Let this command fail
$ sudo dnf system-upgrade upgrade
# Then stop the container just in case

Now Guitarix.so runs inside Reaper.

Fedora 39 is EOL (at least soon), you should delete that box and create one with Fedora 41 if you want to keep it for a while.

I think rawhide in a distrobox is also fine and I will try ti use that. This will avoid the need to recreate the box, but it is unstable, many packages may be testing versions (while others are simply the latest release with no delay, e.g. qgis) and may break.

The issue is that Fedora dnf system-upgrades dont work in the box, at least not the regular way.

Please don’t recommend Rawhide to users. Folks using Rawhide should be well aware that they are using a version for testing.

1 Like

That is true, but unlike OpenSUSE with SlowRoll, Fedora has no alternative to that if you want to avoid replacing boxes at least every year.

There is a way to upgrade containers still for later versions i just neer to check my notes how it was goung

Isn’t the method I used above fit for upgrading the distrobox container? It seems to have worked.

Yeah if it upgrades and downloads everything it works