This, based on what I’ve seen, is a common problem. The Raw Therapee appimage for Linux wants a shared lib called libthai.so which it seems a whole lot of people (including me) don;t have.
So how do we use the appimage without libthai ? Is there a command-line option to exclude the need for that shared lib? Or is there an appimage that we’re not finding that either includes all of the shared libs it needs OR doesn’t require libthai to begin with?
I’m using Slackware with no libthai. The appimage, being a complete independent package, has libthai, but is still insisting on an external copy. How do I get it to use its own instead or simply to work without libthai (I don’t speak Thai, except in cooking (e.g., gai pad khing) and chillis (e.g., prik ki nu). I just need to get Raw Therapee up and running. I’ll try the source. But if anyone can tell me how to use the appimage without it needing an external libthai, that would make it considerably simpler.
Using kubuntu 20.04 and RawTherappee_5.9 appimage.
Since I can unpack it, it is also possible to re-pack it with the libthai.so.0 (libthai.so.0.3.1 renamed) added.
Disabling my system libthai.so.0 (by renaming and that stops a few other things such as my regular file manager) and rebuilt RT works here.
The official appimage
/tmp/.mount_RawTheK8wAQh/AppRun.wrapped: error while loading shared libraries: libthai.so.0: cannot open shared object file: No such file or directory
The rebuilt appimage
embedded profile is not an RGB profile, using sRGB as input profile
If you want to try the rebuild version then it is zipped here:
No guarantee that it works, there is a long list of blacklisted dependencies that appimage assumes installed. Might fail with something else.
Thanks. I was about to give up on Raw Therapee. And it looks like I still might. Missing libdatrie.so.1. I’m not even sure if I need it anymore. I used to use it when I made/sold handmade jewelry for product photos. That home business died the instant COVID 19 hit.
Now the biggest photography app I use, for astrophotography), is Siril.
Thanks anyways. I’m removing Raw Therapee from my install-me list (as I’m rebuilding this Slackware system).
The RT 5.9 appimage comes from the RT download page, so you cannot say that RT has nothing to do with the 5.9 appimage not working when used with (say) slackware.
For other than more usual linux distros there are dependencies missing starting with libthai.so.0 and who knows what else. Chasing dependencies to get it working might be finding one or two files or it might be dozens. For slackware it might be easier compiling RT from source, don’t know, last looked at slackware 20 years ago.
I suppose we could have an AppImage specifically for Slackware that has libthai.so.0 (and any other missing libraries) included. I’ll need to read the documentation to figure out how to do that and I’ll also need help testing it from someone who has a Slackware environment.
By the way, the AppImage does have libdatrie.so.1.
To clarify, I’m not saying libthai doesn’t play well with openSUSE. I’m talking in the context of linuxdeploy. In other words, supposedly there is a combination of libraries and versions bundled by linuxdeploy which does not work on a particular OS when libthai is in the AppImage, but does work when excluded. Also, the official RawTherapee AppImage does include libpango.
The last part where you say the AppImage concept is ok but everything else is broken, I initially took that to mean one should avoid AppImage tools or at least be careful with them when building AppImages. I realized it could also mean AppImages are good in concept, but bad in practice. Could you explain what you mean here? If AppImages are ok, how does one go about learning best practices and how to create AppImages correctly? I’m particularly interested in learning this because the official AppImage documentation features linuxdeploy prominently and it looks like the people from the AppImage team are the ones maintaining linuxdeploy and the exclude list. It’s really surprising if the AppImage people aren’t good at building AppImages themselves.