processing / processing-video

GStreamer-based video library for Processing
274 stars 130 forks source link

linux: no symlinks for libraries #214

Open tgirod opened 1 year ago

tgirod commented 1 year ago

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 commented 10 months 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.

mgunyho commented 8 months ago

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: https://github.com/processing/processing/issues/392