-
-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux: no symlinks for libraries #214
Comments
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 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
because it's looking for 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 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 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: processing/processing#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.The text was updated successfully, but these errors were encountered: