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

Error while loading shared libraries: libheif.so.1 #810

Closed
daniporr opened this issue Aug 10, 2022 · 9 comments · Fixed by #875
Closed

Error while loading shared libraries: libheif.so.1 #810

daniporr opened this issue Aug 10, 2022 · 9 comments · Fixed by #875

Comments

@daniporr
Copy link

I am trying to run linux_czkawka_cli on Linux, but I get the following error:

./linux_czkawka_cli: error while loading shared libraries: libheif.so.1: cannot open shared object file: No such file or directory

Do you know what I need to run it?


In the documentation there is written:

You don't need to have any additional libraries for CLI Czkawka.

But this seems to be false.

And the funniest part is that I do not even need to run it on images!
(I only need the "Empty Directories" functionality and probably the "Duplicate Finder" one)

@qarmin
Copy link
Owner

qarmin commented Aug 17, 2022

Looks heif that library is dynamically loaded from OS(I expected that it will be built into binary, but I was wrong ¯\_(ツ)_/¯)

The problem only happens with prebuilt binaries which use heif feature

run: cargo build --release --features heif

App manually compiled without this option should work fine only with GTK 4 libraries installed

@daniporr
Copy link
Author

Looks heif that library is dynamically loaded from OS(I expected that it will be built into binary, but I was wrong ¯_(ツ)_/¯)

The problem only happens with prebuilt binaries which use heif feature

run: cargo build --release --features heif

App manually compiled without this option should work fine only with GTK 4 libraries installed

Does this mean that everyone who wants to run it on Linux must have that library installed (btw, which one exactly?), or manually build it?

However, I do not have the Rust building tools installed on my machine, so I cannot build it (and I believe many users will be in the same situation), so probably binaries that can be executed without any dependencies should be provided as well.

Moreover, I discovered that the same problem happens with the GUI. Therefore, you cannot run Czkawka at all if you do not have that library or do not manually build it.

@qarmin
Copy link
Owner

qarmin commented Aug 20, 2022

You can download from actions binary without heif support - https://github.com/qarmin/czkawka/actions/runs/2883469684 (czkawka_gui-Linux-1.60.0 and czkawka_cli-Linux-1.60.0 )
On Ubuntu 22.04 this are required libraries to be able to run app

run: sudo apt-get update; sudo apt install libgtk-4-dev libheif-dev -y

@daniporr
Copy link
Author

Thank you for your suggestion.

I downloaded, extracted and tried to run the cli (czkawka_cli-Linux-1.60.0.zip).
Unfortunately, I got the following errors:

./czkawka_cli: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./czkawka_cli)
./czkawka_cli: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./czkawka_cli)
./czkawka_cli: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./czkawka_cli)

I have updated my OS (and all the packages) to their latest versions, but I still get that same error.

Any other suggestions?

@qarmin
Copy link
Owner

qarmin commented Aug 31, 2022

Czkawka require glibc which is available on Ubuntu 22.04 or similar, so for me looks that this error is completely normal.
With 5.0.2 version, official binary not require heif library anymore.

@daniporr
Copy link
Author

daniporr commented Sep 5, 2022

Czkawka require glibc which is available on Ubuntu 22.04 or similar, so for me looks that this error is completely normal.

I have that library, as shown in the error message (you can see the path to it there).
I am not an expert, but I think the problem is with the version of that library.

This is the package in the latest stable version of Debian (Ubuntu is based on Debian):
https://packages.debian.org/source/stable/glibc
As you can see, the latest version is 2.31, while, from that error message, it seems that czkawka_cli is looking for versions '2.32-2.34'.

Can this be the problem?
Why is it looking for such recent versions (that are not supported by the latest stable version of one of the most popular Linux distributions)?

With 5.0.2 version, official binary not require heif library anymore.

I can confirm that in v5.0.2 the problem mentioned in my first message disappeared.

@benedikt-roth
Copy link

I experience the same issue when using macOS:

dyld[78651]: Library not loaded: '/usr/local/opt/libheif/lib/libheif.1.dylib'
  Referenced from: '/Users/I501899/Downloads/mac_czkawka_cli'
  Reason: tried: '/usr/local/opt/libheif/lib/libheif.1.dylib' (no such file), '/usr/local/lib/libheif.1.dylib' (no such file), '/usr/lib/libheif.1.dylib' (no such file)
zsh: abort      ./mac_czkawka_cli

libheif is installed:

brew info libheif
==> libheif: stable 1.13.0 (bottled)
ISO/IEC 23008-12:2017 HEIF file format decoder and encoder
https://www.libde265.org/
/opt/homebrew/Cellar/libheif/1.13.0 (25 files, 2.8MB) *
  Poured from bottle on 2022-09-14 at 15:44:08
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libheif.rb

Looks like the CLI binary is looking in a different folder than where it is installed.

@marmolak
Copy link

marmolak commented Sep 17, 2022

Hello.
It seems like rabbit hole is way more deeper than libheif on macOS.

dyld_info ./mac_czkawka_gui

returns:

/usr/local/opt/libheif/lib/libheif.1.dylib
/usr/local/opt/glib/lib/libgobject-2.0.0.dylib
/usr/local/opt/gtk4/lib/libgtk-4.1.dylib
/usr/local/opt/pango/lib/libpangocairo-1.0.0.dylib
/usr/local/opt/pango/lib/libpango-1.0.0.dylib
/usr/local/opt/harfbuzz/lib/libharfbuzz.0.dylib
/usr/local/opt/gdk-pixbuf/lib/libgdk_pixbuf-2.0.0.dylib
/usr/local/opt/cairo/lib/libcairo-gobject.2.dylib
/usr/local/opt/cairo/lib/libcairo.2.dylib
/usr/local/opt/graphene/lib/libgraphene-1.0.0.dylib
/usr/local/opt/glib/lib/libgio-2.0.0.dylib
/usr/local/opt/glib/lib/libglib-2.0.0.dylib
/usr/local/opt/gettext/lib/libintl.8.dylib

There should be workaround possible with install_name_tool.

I believe, there can be 2 real solutions:

  1. Link binary by using @loader_path/ or @rpath/ - ideally bundle libs and provide installable pkg file. And don't forget to create app bundle for binary itself.
  2. Provide static binary build (which can be impossible or final binary would be too big).

@marmolak
Copy link

marmolak commented Sep 17, 2022

Fast workaround should be:

% install_name_tool -change /usr/local/opt/libheif/lib/libheif.1.dylib /opt/local/lib/libheif.1.dylib ./mac_czkawka_cli

in my case (I'm using macports).

Before change:

% dyld_info ./mac_czkawka_cli | grep libheif
                       /usr/local/opt/libheif/lib/libheif.1.dylib

After change:

% dyld_info ./mac_czkawka_cli | grep libheif
                       /opt/local/lib/libheif.1.dylib

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

Successfully merging a pull request may close this issue.

4 participants