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

Can't use the AppImage on my VPS due to lack of libdrm.so #140

Closed
TheGentleChainsaw opened this issue Oct 14, 2024 · 7 comments
Closed

Can't use the AppImage on my VPS due to lack of libdrm.so #140

TheGentleChainsaw opened this issue Oct 14, 2024 · 7 comments

Comments

@TheGentleChainsaw
Copy link

TheGentleChainsaw commented Oct 14, 2024

So I'm trying to get this program to a point where I can run it on my rented server without having to straight-up build the whole thing on the machine itself. The only problem is that, because it's a VPS and only really meant to be accessed over SSH, it simply doesn't have any graphics drivers installed. I presume this is why the AppImage keeps giving me this error whenever I try to run it:
/tmp/.mount_timg-XXXXXXX/usr/bin/timg: error while loading shared libraries: libdrm.so.2: cannot open shared object file: No such file or directory

I'm not even sure why timg needs libdrm.so when it's designed to print everything to the terminal. It's not like it's required by similar programs like termimage and viu. (EDIT: Ignore those, chafa is a much closer comparison, but I'd still like to know.)

@hzeller
Copy link
Owner

hzeller commented Jan 3, 2025

It looks like the libswscale library used to scale images is depending on the direct rendering manager library.
Maybe it would be useful to have an option for a less quality result scaling library with less dependencies.

@TheGentleChainsaw
Copy link
Author

How about zimg? I've seen other projects use it quite effectively as a libswscale alternative.

@hzeller
Copy link
Owner

hzeller commented Jan 6, 2025

Interesting, didn't know about this, but sounds like a very interesting implementation choice to add when I am looking into abstracting the internal rescale interfaces.

hzeller added a commit that referenced this issue Jan 8, 2025
One place for the image scaling calls.
Preparation to have a compile-time switchable scaler
with less footprint if av-decoding is not selected.

Issues: #140
hzeller added a commit that referenced this issue Jan 8, 2025
SWS is huge, and brings a lot of dependencies not necessarily
desired when we disable video decoding. In that case, just use
STB resizing.

Issue: #140
@hzeller
Copy link
Owner

hzeller commented Jan 8, 2025

Alright, made it now that if video decoding is not linked in (like it is in the appimage), that if falls back to lighter STB image resize.

Can you try the timg-v1.6.1-19-x86_64.AppImage.zip and see if it works for you now ?
(Note, it is zipped, so needs to be unzipped before running)

@TheGentleChainsaw
Copy link
Author

TheGentleChainsaw commented Jan 8, 2025 via email

hzeller added a commit that referenced this issue Jan 8, 2025
hzeller added a commit that referenced this issue Jan 8, 2025
hzeller added a commit that referenced this issue Jan 8, 2025
hzeller added a commit that referenced this issue Jan 8, 2025
  * Semove swscale that was bundled with the appimage but
    not needed anymore.
  * Simplify library checking in CMake - no need to require
    swscale for jpeg,qoi,openslide anymore

Issue: #140
@hzeller
Copy link
Owner

hzeller commented Jan 8, 2025

Oh, I think I forgot to trim the now superfluous swscale library that was still in the image.

Fixed with latest commit; can you try timg-v1.6.1-21-x86_64.AppImage.zip ?

@TheGentleChainsaw
Copy link
Author

Yup, it works now. Thanks for your help!

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