Skip to content
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

Open
tgirod opened this issue Mar 1, 2023 · 2 comments
Open

linux: no symlinks for libraries #214

tgirod opened this issue Mar 1, 2023 · 2 comments

Comments

@tgirod
Copy link

tgirod commented Mar 1, 2023

After installing the library on linux, running an example I get the following error:

can't load library mp3lame (mp3lame|libmp3lame|libmp3lame-0) with -Djna.library.path=/home/tom/sketchbook/libraries/video/library/linux-amd64. Last error:java.lang.UnsatisfiedLinkError: Unable to load library 'mp3lame':
/home/tom/sketchbook/libraries/video/library/linux-amd64/libmp3lame.so: file too short
/home/tom/sketchbook/libraries/video/library/linux-amd64/libmp3lame.so: file too short
/home/tom/sketchbook/libraries/video/library/linux-amd64/libmp3lame.so.0: file too short
Native library (linux-x86-64/libmp3lame.so) not found in resource path (/tmp/processing/Loop1295314071916468227temp:/usr/share/processing/core/library/core.jar:/usr/share/processing/core/library/jogl-all.jar:/usr/share/processing/core/library/gluegen-rt.jar:/home/tom/sketchbook/libraries/video/library/video.jar:/home/tom/sketchbook/libraries/video/library/gst1-java-core-1.4.0.jar:/home/tom/sketchbook/libraries/video/library/jna.jar)
can't load library openh264 (openh264|libopenh264|libopenh264-0) with -Djna.library.path=/home/tom/sketchbook/libraries/video/library/linux-amd64. Last error:java.lang.UnsatisfiedLinkError: Unable to load library 'openh264':
/home/tom/sketchbook/libraries/video/library/linux-amd64/libopenh264.so: file too short
/home/tom/sketchbook/libraries/video/library/linux-amd64/libopenh264.so: file too short
/home/tom/sketchbook/libraries/video/library/linux-amd64/libopenh264.so.6: file too short
Native library (linux-x86-64/libopenh264.so) not found in resource path (/tmp/processing/Loop1295314071916468227temp:/usr/share/processing/core/library/core.jar:/usr/share/processing/core/library/jogl-all.jar:/usr/share/processing/core/library/gluegen-rt.jar:/home/tom/sketchbook/libraries/video/library/video.jar:/home/tom/sketchbook/libraries/video/library/gst1-java-core-1.4.0.jar:/home/tom/sketchbook/libraries/video/library/jna.jar)

(process:34380): libsoup-ERROR **: 12:13:14.745: libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.

looking at the file /home/tom/sketchbook/libraries/video/library/linux-amd64/libmp3lame.so, I realized that instead of being a symlink to libmp3lame.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.

@mgunyho
Copy link

mgunyho commented Aug 20, 2023

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.

@mgunyho
Copy link

mgunyho commented Oct 25, 2023

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:

image

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: processing/processing#392

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants