View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000565||Cinelerra-GG||[All Projects] Bug||public||2021-03-16 12:39||2021-03-16 14:04|
|Platform||x86_64||OS||Arch Based Distro's||OS Version||latest|
|Target Version||Fixed in Version|
|Summary||0000565: Error loding shared Libraries: libdav1d.so.4|
|Description||Cinelerra will not start, running the command "cin" gives following error: |
cin: error while loading shared libraries: libdav1d.so.4: cannot open shared object file: No such file or directory
|Steps To Reproduce||attempt to open application with icon or run terminal command: cin|
NOTE: current cin version is 5.1 20201031
|Additional Information||Current work around is to create a symbolic link from libdav1d.so.5 to libdav1d.so.4|
sudo ln -s /usr/lib/libdav1d.so.5 /usr/lib/libdav1d.so.4
|Tags||No tags attached.|
Your solution is a workaround that works for you and might for others so thank your very much for reporting this. Dav1d has been and will continue to be somewhat of a problem for Cinelerra because it has many requirements making it untenable for older Operating System distros. For example, below is a snippet from the manual:
Problem - 0.6 dav1d requires NASM 2.14 and uses instructions like vgf2p8afﬁneqb,
not exactly an "add" instruction. It also uses meson which is not widely avail-
able on all distros. The only distros that are built for CINELERRA-GG that are
at 2.14 are the latest version of Arch, Debian(10), Gentoo, Tumbleweed, and
Fedora(31). The rest are at 2.12 and 2.13 including the most widely used
Ubuntu. The NASM requirement apparently provides for using AVX-512 in-
structions (like vgf2p8afﬁneqb, which is more like a whole routine than a
Workaround already in use by CINELERRA-GG - a Makeﬁle was generated to re-
place Meson usage but has to be continuously updated for new releases.
Dav1d 0.5 requires NASM 2.13 so at this level the newer distros mostly work.
The availability of meson and nasm are a signiﬁcant problem on many sys-
tems which are still in wide use.
However, we have switched from the monthly tars/packages builds (the last one was 10312020) to AppImage which should solve the library link problem you have noticed and future library updates.