Linux tech help! Appimage won't launch, missing shared libraries.
On the latest Fedora KDE. I'm trying to run an app image and it just does nothing. I tried doing it with Gear Lever which popped it into my app launcher. If I tell Gear Lever to launch it, it looks busy for about 5 seconds then nothing happens. I click it on my app launcher, bouncy icon by my mouse for like 10 seconds, nothing happens.
So I ran it in konsole and it says it doesn't see the image in the usual spot so it launches directly. Then it says it can't find preload library so it creates a temp file for it. The notable line after that is:
error while loading shared libraries: libwebkit2gtk-4.1.so.0: cannot open shared object file: no such file or directory
So I try to install it via the terminal and it says failed to resolve, no match for argument...
What gives?
Thanks in advance for any help.
dead [he/him] - 2w
Please be extremely careful when deciding whether to trust an appimage. I would only run an appimage in a very rare circumstance. Most software should be installed from the distro repository and if it isn't in the distro repository, then I would use flatpak.
This seems to be the package you are missing. You would install it with the package manager for fedora.
To provide a little more background, .so files ("shared objects") are the Unix equivalent of .dll files ("dynamically linked libraries") on Windows. They contain a collection of software routines which are shared between various programs (in this case, the ability to embed a browser engine within a GTK application). On a technical level, they provide the benefit that code in a shared object only needs to be stored on the disk and loaded into memory once, regardless of how many programs make use of it. Unlike Windows, these files are versioned (which is why you'll often see numbers after the .so suffix). For the most part, they are stored in /usr/lib or /usr/lib64
When you run a program, a part of the operating system called the dynamic linker will search for all the required libraries (also known as dependencies) as a prerequisite to starting the program. If the dynamic linker fails to find any of the needed dependencies, you get an error message like the one shown above. The circumstance of needing to track down many arbitrary dependencies, many of which may have their own dependencies, is known as "dependency hell." It is the fundamental problem which package managers solve, and can quicky become a burden when working around them.
AppImages are supposed to "solve" this problem as well by bundling all their needed dependencies, but in practice a lot of them still seem to make assumptions about what libraries and utilities are present on your machine. I'm not as well versed in the technical details.
9
tactical_trans_karen [she/her, comrade/them] - 2w
This is immensely helpful for me to understand things, thank you. Feel free to continue sharing knowledge!
A lot of times when someone gives answers about Linux stuff it's sorely lacking this kind of explanation. Like, spelling out acronyms and their meaning is huge.
4
tactical_trans_karen [she/her, comrade/them] - 2w
Okay... So I swear I did that first command before and it basically said 'idk lol' but this time it worked! I'm holding off on using the app image though.
It's a 3d printer slicer software that I've used for quite some time. I got it directly from the manufacturer... I should be good, yeah? It's not available as flatpak or any repositories. But they do have the source code in .tar.gz files available. But I have zero knowledge of how to manually compile a program, let alone audit the code...
2
bobs_guns @lemmygrad.ml - 2w
I think it is most likely not a problem. It would be bad for their business if they installed malware on their client PCs. It is somewhat of a security risk but exactly how much depends on your threat model. If there's no good reason for the CIA or Mossad to personally be targeting you I would say it would probably not be an issue.
3
tactical_trans_karen [she/her, comrade/them] - 2w
Yeah, the app image auto updates and it's an industrial grade printer company. My threat model doesn't include that level of concern, if it did I'd probably be boned because I'm asking security advice on an obscure lefty internet forum...
2
PorkrollPosadist [he/him, they/them] - 2w
But they do have the source code in .tar.gz files available. But I have zero knowledge of how to manually compile a program, let alone audit the code...
Yeah that's a whole 'nother rabbit hole. Not to say it is exceptionally difficult or anything (I do it for a couple programs), but it basically goes back to the dependency hell thing where it becomes your responsibility to track down all the dependencies and install them yourself (now including build-time dependencies like compilers, build automation systems, header files, etc), as well as update it manually. It can be worthwhile if you specifically want to try the bleeding edge version of a program, like if the specific bug you're experiencing got fixed last night, or if you want to try an experimental branch someone is working on, or if it is such a small project that nobody has taken the time to package it in any other form. Otherwise, these changes trickle into the stable distribution packages eventually (fairly quickly in Fedora).
AppImages have a couple downsides, but that's all they are - downsides. When weighed against alternatives, they are still often worth it. It isn't like an evil technology or anything. You need to trust whoever you're getting it from, naturally. No surprises there. There is no holistic update mechanism which can update all your AppImages the way your distro package manager can update your entire system - though some apps will implement their own self-update mechanisms. And because they bundle many of their dependencies, the updates applied by your distro package manager don't apply to them. If an AppImage bundles (e.g.) the cURL library and your distro updates its cURL library to a newer version, the AppImage will continue using whatever version of cURL is bundled inside of it. After a long enough period of time, un-patched security vulnerabilities can accumulate this way (basically the same security implications of unzipping and running a program on Windows that you downloaded N years ago).
On the other hand, it is more convenient for a lot of commercial software companies to put together one AppImage rather than build, package, and test their software for a dozen different distributions. Distribution packages for software like this, when they exist, are almost always created by third party volunteers affiliated with the distro rather than that specific software developer.
3
tactical_trans_karen [she/her, comrade/them] - 2w
Thank you, again, this helps allot.
1
stupid_asshole69 [none/use name] - 2w
The package you need isn’t libwebkit2gtk it’s webkit2gtk
Decades of package management getting us off manual dependency resolution and here comes appimages to put us right back to 1999, the first documented year of the linux desktop.
E: someone already said this. Late to the party again.
5
tactical_trans_karen [she/her, comrade/them] - 2w
Ah, I see now, was the problem!
I'm getting kinda sus about this distro tbh. When shit is scrolling past on the terminal it says stuff like "lib" and "post-trans" among other things. Is it mocking me?
8
stupid_asshole69 [none/use name] - 2w
Eh, if you can make a spare email I don’t see much benefit to running fedora over actual factual red hat.
When I get home I’ll confirm the invocation on a dnf machine, but something like dnf search string ought to let you find the right packages on the command line.
tactical_trans_karen in technology
Linux tech help! Appimage won't launch, missing shared libraries.
On the latest Fedora KDE. I'm trying to run an app image and it just does nothing. I tried doing it with Gear Lever which popped it into my app launcher. If I tell Gear Lever to launch it, it looks busy for about 5 seconds then nothing happens. I click it on my app launcher, bouncy icon by my mouse for like 10 seconds, nothing happens.
So I ran it in konsole and it says it doesn't see the image in the usual spot so it launches directly. Then it says it can't find preload library so it creates a temp file for it. The notable line after that is:
error while loading shared libraries: libwebkit2gtk-4.1.so.0: cannot open shared object file: no such file or directorySo I try to install it via the terminal and it says failed to resolve, no match for argument...
What gives? Thanks in advance for any help.
Please be extremely careful when deciding whether to trust an appimage. I would only run an appimage in a very rare circumstance. Most software should be installed from the distro repository and if it isn't in the distro repository, then I would use flatpak.
This seems to be the package you are missing. You would install it with the package manager for fedora.
https://packages.fedoraproject.org/pkgs/webkitgtk/webkit2gtk4.1/
I think you would do something like
or
To provide a little more background,
.sofiles ("shared objects") are the Unix equivalent of.dllfiles ("dynamically linked libraries") on Windows. They contain a collection of software routines which are shared between various programs (in this case, the ability to embed a browser engine within a GTK application). On a technical level, they provide the benefit that code in a shared object only needs to be stored on the disk and loaded into memory once, regardless of how many programs make use of it. Unlike Windows, these files are versioned (which is why you'll often see numbers after the.sosuffix). For the most part, they are stored in/usr/libor/usr/lib64When you run a program, a part of the operating system called the dynamic linker will search for all the required libraries (also known as dependencies) as a prerequisite to starting the program. If the dynamic linker fails to find any of the needed dependencies, you get an error message like the one shown above. The circumstance of needing to track down many arbitrary dependencies, many of which may have their own dependencies, is known as "dependency hell." It is the fundamental problem which package managers solve, and can quicky become a burden when working around them.
AppImages are supposed to "solve" this problem as well by bundling all their needed dependencies, but in practice a lot of them still seem to make assumptions about what libraries and utilities are present on your machine. I'm not as well versed in the technical details.
This is immensely helpful for me to understand things, thank you. Feel free to continue sharing knowledge! A lot of times when someone gives answers about Linux stuff it's sorely lacking this kind of explanation. Like, spelling out acronyms and their meaning is huge.
Okay... So I swear I did that first command before and it basically said 'idk lol' but this time it worked! I'm holding off on using the app image though.
It's a 3d printer slicer software that I've used for quite some time. I got it directly from the manufacturer... I should be good, yeah? It's not available as flatpak or any repositories. But they do have the source code in .tar.gz files available. But I have zero knowledge of how to manually compile a program, let alone audit the code...
I think it is most likely not a problem. It would be bad for their business if they installed malware on their client PCs. It is somewhat of a security risk but exactly how much depends on your threat model. If there's no good reason for the CIA or Mossad to personally be targeting you I would say it would probably not be an issue.
Yeah, the app image auto updates and it's an industrial grade printer company. My threat model doesn't include that level of concern, if it did I'd probably be boned because I'm asking security advice on an obscure lefty internet forum...
Yeah that's a whole 'nother rabbit hole. Not to say it is exceptionally difficult or anything (I do it for a couple programs), but it basically goes back to the dependency hell thing where it becomes your responsibility to track down all the dependencies and install them yourself (now including build-time dependencies like compilers, build automation systems, header files, etc), as well as update it manually. It can be worthwhile if you specifically want to try the bleeding edge version of a program, like if the specific bug you're experiencing got fixed last night, or if you want to try an experimental branch someone is working on, or if it is such a small project that nobody has taken the time to package it in any other form. Otherwise, these changes trickle into the stable distribution packages eventually (fairly quickly in Fedora).
AppImages have a couple downsides, but that's all they are - downsides. When weighed against alternatives, they are still often worth it. It isn't like an evil technology or anything. You need to trust whoever you're getting it from, naturally. No surprises there. There is no holistic update mechanism which can update all your AppImages the way your distro package manager can update your entire system - though some apps will implement their own self-update mechanisms. And because they bundle many of their dependencies, the updates applied by your distro package manager don't apply to them. If an AppImage bundles (e.g.) the cURL library and your distro updates its cURL library to a newer version, the AppImage will continue using whatever version of cURL is bundled inside of it. After a long enough period of time, un-patched security vulnerabilities can accumulate this way (basically the same security implications of unzipping and running a program on Windows that you downloaded N years ago).
On the other hand, it is more convenient for a lot of commercial software companies to put together one AppImage rather than build, package, and test their software for a dozen different distributions. Distribution packages for software like this, when they exist, are almost always created by third party volunteers affiliated with the distro rather than that specific software developer.
Thank you, again, this helps allot.
The package you need isn’t libwebkit2gtk it’s webkit2gtk
Decades of package management getting us off manual dependency resolution and here comes appimages to put us right back to 1999, the first documented year of the linux desktop.
E: someone already said this. Late to the party again.
Ah, I see now,
was the problem!
I'm getting kinda sus about this distro tbh. When shit is scrolling past on the terminal it says stuff like "lib" and "post-trans" among other things. Is it mocking me?
Eh, if you can make a spare email I don’t see much benefit to running fedora over actual factual red hat.
When I get home I’ll confirm the invocation on a dnf machine, but something like dnf search string ought to let you find the right packages on the command line.