Mpv: symbol lookup error

Having an issue here:

$ mpv
mpv: symbol lookup error: mpv: undefined symbol: archive_read_support_format_rar5

Found this link, that pointed me to running:

$ ldd $(which mpv) | grep libarchive => /home/ppp/.SynologyDrive/ (0x00007f49ae600000)
$ objdump -T /home/ppp/.SynologyDrive/ | grep rar5
objdump: /home/ppp/.SynologyDrive/ no version information available (required by /usr/lib/

So, the SynologyDrive app seems to be the culprit of this problem. (Did the installation mess up some environment paths?) Via this forum post, and this link, I found a workaround, running mpv via a shell script:

export LD_PRELOAD=/usr/lib/
exec /usr/bin/mpv "$@"

But, I would prefer things working like before again.

  • How can I change my system to use /usr/lib/, instead of /home/ppp/.SynologyDrive/

  • And is there a way to check if such a change will break anything, like the SynologyDrive app, before I make the change?

I wonder how it was installed? Normally, ldd should not point to your home folder. It has probably updated the ldd cache? Did you install a deb package as root?

That would be a terrible behavior for a portable app.

Cache is located here: /etc/ maybe remove it and recreate it?

sudo mv /etc/ /etc/
sudo ldconfig --verbose

Thanks for getting back to me!

I installed it using pamac, from aur, as a normal user (not root).

I tried re-caching, but unfortunately it did not make any difference. I still get the same error.

Please check the cache:

 ldconfig -p | grep "/home"

If so, why is it not in /opt/Synology/SynologyDrive/lib, but in /home/ppp/.SynologyDrive/ ? That makes me thinking.

ldconfig -p | grep "/home" returns nothing. Hmm…

Then I guess it has a local cache or the variable LD_LIBRARY_PATH is set somewhere wrong. I can imagine that you set /home/ppp/.SynologyDrive/ first to the search path and then /usr/lib, what would lead to such a behavior.

1 Like

Thanks a lot for your help, @megavolt. I’ll see if I find out where this happens.

I found that
contains this line:
Exec=sh -c 'env "LD_LIBRARY_PATH=$HOME/.SynologyDrive/" "$HOME/.SynologyDrive/" --open-file "'%f'"'

I guess that is the reason for this issue. Am I right about that? If yes, is the right path forward to contact the package maintainer?

[Desktop Entry]
Name=Synology Drive
Comment=Synology Drive
Exec=sh -c 'env "LD_LIBRARY_PATH=$HOME/.SynologyDrive/" "$HOME/.SynologyDrive/" --open-file "'%f'"'

$ cd /opt/Synology/SynologyDrive/
3-Name=Synology Drive
4-Comment=Synology Drive
5:Exec=sh -c 'env "LD_LIBRARY_PATH=$HOME/.SynologyDrive/" "$HOME/.SynologyDrive/" --open-file "'%f'"'

48:	env LD_LIBRARY_PATH="$APP_PATH/lib" QT_QPA_PLATFORMTHEME=gnome QT_QPA_FONTDIR=/usr/share/fonts/truetype QT_PLUGIN_PATH="$APP_PATH/lib/plugins" $UI_PATH &
54-	#wait for gnome-shell ready
55-	sleep 10
56:	env LD_LIBRARY_PATH="$APP_PATH/lib" QT_QPA_PLATFORMTHEME=gnome QT_QPA_FONTDIR=/usr/share/fonts/truetype QT_PLUGIN_PATH="$APP_PATH/lib/plugins" $UI_PATH &
59-case $1 in

Normally, it should only apply for SynologyDrive… and well… why does this use that ugly sh command? Wouldn’t that be better?

Exec=env LD_LIBRARY_PATH="./lib/" ./bin/cloud-drive-ui --open-file %f

But get that. You cannot use Shell Variables like $HOME in a Desktop file. It is rather a crippling solution, what they have done. A little script would be much better than using the Desktop file for that.

However… when LD_LIBRARY_PATH is set somewhere, then you should get an output here:

1 Like

Yes, it is not ideal at all. I will try to reach out to Synology. Hopefully they can find a better way of doing this.

In the meantime you can experiment with usurping their desktop file.
Copy to ~/.local/share/applications and edit that version of the desktop file and it should take precedence.

1 Like

Just for the record, this is what Synology did reply:

Upon investigation, we have found that our Synology Drive Client app is not compatible with your version of Linux. As per our software specifications, the supported operating systems for our app are Windows 7 and above (excluding Windows 10 on ARM and Windows Server editions), macOS 10.14 and above (64-bit), and Ubuntu 18.04 and above (officially supported versions). Manjaro Linux x86_64 is not currently supported.

We kindly advise that you upgrade your operating system to a supported version of Ubuntu or consider using one of the other supported operating systems such as Windows or macOS. We apologize for any inconvenience this may cause and we appreciate your understanding.

What the cache shows for libarchive?

ldconfig -p | grep libarchive

Also, do you see anything unusual in /etc/

That is a default excuse mail. Don’t expect any support there when using Manjaro xD

That was a run to make it running on sway (wayland):

pamac build synology-drive
# copy the portable package (normally should be $HOME/.SynologyDrive/
cp -r /opt/Synology/SynologyDrive/package/cloudstation/ ~/cloudstation
# Remove this config:
rm ~/cloudstation/bin/qt.conf
# preload needed libs since here it needs these special libs:
export LD_PRELOAD=$HOME/cloudstation/lib/$HOME/cloudstation/lib/$HOME/cloudstation/lib/
# Set the system path plugins:
export QT_PLUGIN_PATH=/usr/lib/qt/plugins
# Specify that it has to use Xorg
export QT_QPA_PLATFORM=xcb 
# switch dir and run it:
cd ~/cloudstation/bin && ./cloud-drive-ui

However, I did that only for testing. I guess that could be somehow packaged as an AppImage, so that your issue would not happen.

1 Like
$ ldconfig -p | grep libarchive (libc6,x86-64) => /usr/lib/ (libc6,x86-64) => /usr/lib/
$ ls /etc/
fakeroot.conf  lib32-glibc.conf

Thank you, @megavolt! Great support in this forum though. and I love Manjaro XD

This doesn’t make much sense to me. If your system is correctly detecting the right library for libarchive, it doesn’t make much sense that mpv uses other. I have been able to find discrepancies like this only when 32bit/64bit executables and libraries are mixed (i.e. 32 bit executable doesn’t find a 64 bit library)

Also I suppose that mpv is the one from Manjaro repository and you are executing it from the command line

Thanks for looking into this. I agree, it is weird. And yes, mpv is from the Manjaro repo and I am running it from the command line.

]$ mpv movie.mp4 
mpv: symbol lookup error: mpv: undefined symbol: archive_read_support_format_rar5
]$ ldd $(which mpv) | grep libarchive => /home/poq/.SynologyDrive/ (0x00007f4c42e00000)
]$ ldconfig -p | grep libarchive (libc6,x86-64) => /usr/lib/ (libc6,x86-64) => /usr/lib/

Only thing I could imagine here, that you run an auto-update of synology-drive which cause that issue. Also check your environment files:


I run it and don’t have such an issue.

1 Like

Good tips. I checked my environment files but found nothing out of the order. But it might be related to some update, as after reinstalling mpv and rebooting the system it once again is working.