Tag: gentoo

Fix DaVinci Resolve installation (symbol lookup errors)

This post is mostly for my future self, but feel free to use the one-liner if you have just installed or upgraded BlackMagic DaVinci Resolve (Studio) onto your Linux machine and it’s not starting because of symbol lookup errors, e.g. /opt/resolve/bin/resolve: symbol lookup error: /usr/lib64/libpango-1.0.so.0: undefined symbol: g_string_free_and_steal.

One-liner

for lib in $(ldd /opt/resolve/bin/resolve | cut -d' ' -f1);
do
  [ -f "/usr/lib/${lib}" ] \
  && [ -f "/opt/resolve/libs/${lib}" ] \
  && { echo "Found ${lib} in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/${lib}" \
       && sudo rm "/opt/resolve/libs/${lib}"; } \
done

Example output

pn@vision ~ $ for lib in $(ldd /opt/resolve/bin/resolve | cut -d' ' -f1);
do
  [ -f "/usr/lib/${lib}" ] \
  && [ -f "/opt/resolve/libs/${lib}" ] \
  && { echo "Found ${lib} in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/${lib}" \
       && sudo rm "/opt/resolve/libs/${lib}"; } \
done
Found libavformat.so.60 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libavformat.so.60
Found libavcodec.so.60 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libavcodec.so.60
Found libavutil.so.58 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libavutil.so.58
Found libswscale.so.7 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libswscale.so.7
Found libmp3lame.so in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libmp3lame.so
Found libgstreamer-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstreamer-1.0.so.0
Found libgobject-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgobject-2.0.so.0
Found libglib-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libglib-2.0.so.0
Found libgstbase-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstbase-1.0.so.0
Found libgstapp-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstapp-1.0.so.0
Found libgstrtp-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstrtp-1.0.so.0
Found libgstvideo-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstvideo-1.0.so.0
Found libgstsdp-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstsdp-1.0.so.0
Found libgstpbutils-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstpbutils-1.0.so.0
Found libgstaudio-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstaudio-1.0.so.0
Found libgsttag-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgsttag-1.0.so.0
Found libgstwebrtc-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstwebrtc-1.0.so.0
Found libgio-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgio-2.0.so.0
Found libgmodule-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgmodule-2.0.so.0
Found liborc-0.4.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/liborc-0.4.so.0

Explanation

  1. ldd is used to get a list of all shared libraries that the DaVinci Resolve executable (/opt/resolve/bin/resolve) links against
  2. The for loop iterates over these collected filenames and for each checks whether it’s both present in the standard library path (/usr/lib) and in DaVinci Resolve’s own libs directory (/opt/resolve/libs).
  3. If that is the case, they’re deleted from /opt/resolve/libs, so that only the ones coming with the distro remain.

Why does this work?

Some shared libraries (those that the one-liner deletes) that come with DaVinci Resolve are older versions that are not compatible with other libs that come with your distro.

At the time of writing there are 20 such libs, see in the Example Output section for a list.

By deleting them, the loader will find the ones in /usr/lib instead. These are compatible with the aforementioned other libs from your distro, because they are coming from your distro.

I’ve written the one-liner for DaVinci Resolve 19.1.2 and tested it with it on my Gentoo system. It should work on other distros as well.

Wayland, finally.

I’ve been watching the Wayland development from afar for a couple of years now, probably since 2014. But whenever I gave it a try, after less than 10 minutes something was so obviously broken that I immediately went back to X11.

Until yesterday, when I decided to give it another try. The trigger was, that KDE/Plasma felt sluggish on my machine. Even though it has decent specs (12 core Ryzen, Nvidia 4060 Ti, fast NVMe), opening a simple application like Konsole takes 1.5+ seconds. Even clicking the start menu button has a noticeable delay (~300-500ms). On X11 that is.

After rebuilding a bunch of packages (because I had to toggle the ‘wayland’ USE flag on, which had previously been off in my Gentoo installation), I chose the “Plasma (Wayland)” item in the SDDM dropdown and logged in. To my surprise KDE/Plasma instantly felt much better. No more delays, very smooth animations, etc.

IMO there must be serious bugs in Qt or KDE to have such bad performance on X11 nowadays. Using a simple Window Manager (Fluxbox) I didn’t feel any lags on X11. Even launching Konsole or other KDE apps from an xterm is snappy. But I don’t have the time and energy to do serious profiling, and I also really want to use KDE/Plasma.

So I’m happy that I didn’t find any issues with Wayland in the hours since. For a few minutes I thought screen recording was broken, but then it turned out that I just had to enable the ‘screencast’ USE flag and do a few rebuilds.

Will have to spend some time learning all the underlying concepts and new terms – but that doesn’t prevent me from using Wayland.

I’ll post updates here if / when I encounter issues.

Update (2025-01-05)

Today I wanted to write in German for the first time, and noticed that my .Xmodmap keyboard remapping for Umlauts no longer works. That was already problematic in X11 for a while, but it was a good solution that I’d been using for many years (and even “ported” to Windows – see here – when I had to use Windows at work).

So now I had to figure out something new. A guy in the always helpful German #gentoo-de@libera.chat IRC channel told me about the “EurKEY” keyboard layout – “The Layout for Europeans, Coders and Translators” – covers pretty much all European languages with one layout. Love it. And they took the exact same approach that I did: on an English keyboard, use a modifier key and when it’s pressed, “a” becomes “ä”, “o” becomes “ö” and so on. It comes out of the box in KDE, just had to choose it from the dropdown list!

The only issue with that is: they’re using the right ALT key as modifier, and I have nearly two decades worth of muscle memory using the Meta/Windows key as modifier. It would take a while to retrain myself, so I decided to instead remap the Meta/Windows key to the right ALT key. Works perfectly. Phew, problem solved.

Fast SFTP transfers with KDE / kio-extras / Dolphin

For a few years now, I’ve used Dolphin / Konqueror / Krusader for transferring files to or from my home server via SFTP. However when there were larger amounts to be transferred, I opened the shell and used rsync. That’s because I felt it was always somewhat slower with SFTP. I blamed it on the weak file server, on the network, or whatever.

Recently I again wanted to clean up my desktop’s home directory, where a bunch of raw or edited videos were sitting. All in all ~250 GiB. Because I wanted to sort the videos into different sub-directories on the server, I used Dolphin and SFTP once again. While I was watching the transfer, I began to doubt whether the network between my desktop and the home server was actually Gigabit, because I only saw 10-15 MiB/s. Quick check with rsync and scp: nope, 80+ MB/s is possible, just not with Dolphin.

That’s when I decided to get to the bottom of the issue. I discovered KDE bug 296526 – Dolphin is too slow when upload a file on a SSH server. It fit exactly what I was observing, even though it’s from 2012. That’s 14 years! I went on to read all the comments, and it became apparent that none of the users that had commented had spent the time to do a proper side-by-side comparison, and document it properly. So I took up that task and posted comment 40, where I wrote pretty much what I wrote here, but also the results of some tests that I had done with ‘libssh’. That’s the underlying library which kio-extras/sftp uses to interact with SSH/SFTP servers. And Dolphin / Konqueror / Krusader in turn use kio-extras/sftp to do SFTP transfers.

These tests showed very promising results: I could actually saturate my Gigabit link and transfer >750 Mbps. What I didn’t know at that time (September): I had tested a brand new version of libssh (0.11.0), released in August, that came with major changes. Namely a new async I/O API had been added. The transfers with Dolphin had still used libssh 0.10.x though.

Upon learning about these important changes, I opened a version bump request for libssh 0.11.0 in Gentoo’s bug tracker to make the Gentoo devs aware of this new libssh version. Fast forward two months, libssh 0.11.1 was available in Gentoo. I then erroneously tested with kio-extras linked against libssh 0.10.x (and thus disabled new async I/O API), even though I had 0.11.1 on my system. The reason was, that I hadn’t rebuilt kio-extras. That resulted in comment 45. A few minutes later I realized my error, rebuilt kio-extras (actually most of KDE, because an update was coming in anyway), and voilà: ~230 MiB/s or ~1840 Mbps (with peaks going >2 Gbps)! Hurray!

Side note: I had upgraded my network from Gigabit to 2.5 Gigabit in the meantime, otherwise that would obviously not be possible. But with the old libssh only around ~90 MiB/s or ~720 Mbps were possible over the same network, 2.5x slower than with the new libssh 0.11.x.

So, if you find that your SFTP transfers in KDE are slower than they should be, check which libssh version comes with your distribution. If it’s <0.11.0, you know you need to upgrade. With non-rolling binary distributions, you’ll probably have to wait a bit and then upgrade your whole distribution. For example Ubuntu will only get libssh 0.11.1 in “Plucky” aka version 25.04. For rolling distributions like Gentoo or Arch it’s already available.

This is probably the biggest single improvement to my Linux on the Desktop experience of the last years… hence this blog post 🙂