libthai in excludelist causes problems

[krushia]

https://github.com/AppImageCommunity/pkg2appimage/blob/c302f81c56d5e37d752a78fc4e1854d36cb09345/excludelist#L119

This breaks several appimages by assuming a Thai language library will be present on any host system. Known to be missing on several installs of Arch, Debian, Gentoo, Nix, and Slackware. A small sampling of references:

https://github.com/tauri-apps/tauri/issues/4930 https://github.com/pineappleEA/pineapple-src/issues/85 https://github.com/xournalpp/xournalpp/issues/4660 https://github.com/cjcliffe/CubicSDR/issues/852 https://discourse.appimage.org/t/how-do-distros-add-support-for-running-appimages/1648/8

[bashfulrobot]

While this is my own. I wanted to add another example where it breaks an appimage.

But it looks like it is on it's way in. 👍

[probonopd]

• If we don*t bundle it, target systems that don't have it installed get an issue
• If we bundle it, target systems that have a newer version installed get an issue

So we would need a way to determine, at runtime, which one is newer; the one on the system or the one in the AppImage.

[phil294]

If we bundle it, target systems that have a newer version installed get an issue

sorry, but why? How is libthai different from any other package on the excludelist? In other words, why does this problem not exist for others?

[probonopd]

Good question.

[ImUrX]

So we would need a way to determine, at runtime, which one is newer; the one on the system or the one in the AppImage.

is this something that is done already? that you just have an array of and we can just append another package in? Or should this be done with a custom handler just for libthai?

[probonopd]

So we would need a way to determine, at runtime, which one is newer; the one on the system or the one in the AppImage.

is this something that is done already?

I don't remember that anyone has done that yet, but maybe @TheAssassin or @azubieta have a solution for that. Ideally we would find a way that would work with all libraries.

(Please note that pkg2appimage is only a last resort solution; it's better to ask the application author to provide an officially made, tested, and supported AppImage.)

[ImUrX]

I'm one of the app authors, but the ones providing the solution to packing the appimage is the framework we using which is Tauri.

(You can see the issue from Tauri that references it in tauri-apps/tauri#4930)

[azubieta]

Hi @probonopd, I had somethingo done for libc (glibc) abd libc++ but not for libthai, it would require a special launcher that compares the library versions and pics the correct one.

[TheAssassin]

I guess people who need this need to handle this in their deployment specifically. https://github.com/darealshinji/linuxdeploy-plugin-checkrt for instance allows bundling a libstdc++ implementing a version check to load it only when needed. This really sounds like there is a need for a linuxdeploy-plugin-libthai. It can't be fixed here.

[probonopd]

..or a modified ld-linux loader that compares the versions inside and outside the bundle for all libraries...

[TheAssassin]

Sounds like a recipe for disaster...

[probonopd]

...indeed. Scary!

[TheAssassin]

If we bundle it, target systems that have a newer version installed get an issue

Is that confirmed? I don't see any references in this issue. As far as I can see it, it shouldn't matter, really.

Edit: the only comment that ever mentioned problems is https://github.com/AppImageCommunity/pkg2appimage/issues/538#issuecomment-1650568945, but there is no reference to some concrete issue or a minimal example to reproduce...

[probonopd]

https://github.com/AppImageCommunity/pkg2appimage/blob/48a9bbfa8f94b224192647dca4f54ea209559b79/excludelist#L123-L126

[TheAssassin]

That just means we have to bundle both libpango and libthai, doesn't it?

[koppor]

I am tryting the AppImage of gitbutler and run into the same issue. Did you find some recipe to work-around this?

[probonopd]

One way would be to use a tool that can bundle everything, like go-appimage -s deploy.

[Korne127]

Hey, I stumbled across this and I feel like it has been forgotten or overshadowed by other things. But it's still a current issue and as the excludelist is also used by Linuxdeploy, this affects AppImages built with it as well. Gentoo still doesn't have libthai.so.0, and the many references to this issue show that other distributions don't have it as well. Therefore, this still defeats the core concept of AppImages not depending on resources that aren't available on all modern used dependencies.

I went back and tried to find the original issue due to which it has been put on the excludelist, but could only find the similar issue https://github.com/cjcliffe/CubicSDR/issues/655. As @TheAssassin said, it seems like the issue is that when libpango is not bundled (so the system version is used) but libthai is bundled, such a version mismatch can create this error.

However, since then, libpango has been removed again from the excludelist in 2022. This means that the original reason why libthai is excluded is no longer relevant.

Therefore, I think this can finally be resolved by just removing libthai from the excludelist. @probonopd (Ping so you can see this (as you seem to mostly update the excludelist)).

I tried to use linuxdeploy with --library /lib/x86_64-linux-gnu/libthai.so as a workaround, but that didn't work / it still gave the error that the library is missing. (Edit: This has been solved by using --library /lib/x86_64-linux-gnu/libthai.so.0 instead.)