Open tgirod opened 1 year ago
I also had this error with basically all libraries. I wrote a small python script to convert all the text files to symlinks. Put it in the folder next to the text/so files and run with python3 scriptname.py
from pathlib import Path
import glob
for fname in glob.glob("*.so*"):
if fname.endswith("_") or Path(fname).is_symlink():
continue
with open(fname, "rb") as f:
if f.read(4) == b'\x7fELF':
# skip the actual libs
continue
f.seek(0)
link_target = f.read().decode("utf-8")
target_fname = fname + "_"
print(f"renaming {fname} to {target_fname}")
Path(fname).rename(target_fname)
print(f"creating symlink {fname} => {link_target}")
Path(fname).symlink_to(link_target)
Then, I still got an error
can't load library libgstcodecs-1.0 (libgstcodecs-1.0|liblibgstcodecs-1.0|liblibgstcodecs-1.0-0) with -Djna.library.path=
~/sketchbook/libraries/video/library/linux-amd64. Last error:java.lang.UnsatisfiedLinkError: Unable to load lib
rary 'libgstcodecs-1.0':
liblibgstcodecs-1.0.so: cannot open shared object file: No such file or directory
liblibgstcodecs-1.0.so: cannot open shared object file: No such file or directory
/usr/lib64/libgstcodecs-1.0.so.0.2205.0: undefined symbol: gst_h265_parser_identify_and_split_nalu_hevc
because it's looking for liblibgstcodecs-1.0.so
, which I think is a typo: it should be just gstcodecs
here (I'm not 100% sure). I fixed this by just creating a symlink:
ln -s libgstcodecs-1.0.so liblibgstcodecs-1.0.so
After this, I still had to manually download libffi.so.7 (because my distro only has .so.8), see #219.
I looked at this today, and I realized that the problem is probably related to unzipping the library archive. If I download the latest release from Github, Ark (KDE archive manager) shows the files with the mode l...
, so they are symlinks inside the release zip:
If I unzip them using Ark, the symlinks are converted to just plain files where the content is the destination of the symlink, as described in this issue. However, if I unzip with the unzip
command on the CLI, they remain symlinks and it works!
I found the code where Processing unzips the downloaded libraries here: https://github.com/processing/processing/blob/master/app/src/processing/app/Util.java#L621 I searched around a bit to see if unzipping a file with Java preserves the symlinks and couldn't find a clear answer, but it seems like it doesn't. But then again, that code has not been changed in 4 years (and the previous version which should behave the same is from 8 years ago), so I don't understand why this worked earlier but doesn't work anymore. Maybe earlier it was always using the system libs so nobody noticed that the bundled ones are broken?
I also found this issue, which seems related: https://github.com/processing/processing/issues/392
After installing the library on linux, running an example I get the following error:
looking at the file
/home/tom/sketchbook/libraries/video/library/linux-amd64/libmp3lame.so
, I realized that instead of being a symlink tolibmp3lame.so.0.0
, it is just a text file with the filename of the actual library. If I replace the file by a proper symlink, it does not complain anymore.