AppImageCommunity / pkg2appimage

Tool and recipes to convert existing deb packages to AppImage
http://appimage.org
MIT License
697 stars 216 forks source link

Excludelist changes (Related to Arch Linux) #171

Open Anti-Ultimate opened 7 years ago

Anti-Ultimate commented 7 years ago

I'm compiling an AppImage of the Dolphin Emulator on Ubuntu 14.04 with GCC 5

This is the script (minus some changes to get it to compile on Ubuntu 14.04 - those are currently only in the VM and I really don't want to start that right now) http://pastebin.com/BwdRm4QK

Running the resulting AppImage on Antergos/Arch Linux complains about the following libraries missing:

libkrb5.so.26 => not found libhcrypto.so.4 => not found libroken.so.18 => not found

While Arch Linux does carry these libraries in their repositories, they aren't the same versions and being in the nature of Rolling distributions, there are no symbolic links to maintain compatibility either. So I suggest these libraries disappear from the black list.

Anti-Ultimate commented 7 years ago

This is the final script which made a AppImage on Ubuntu 14.04 that works on an Antergos LiveCD

http://pastebin.com/i0rrb5k7

probonopd commented 7 years ago

Thanks @Anti-Ultimate

Hardly anyone ever actually uses Kerberos, so maybe it could best be patched away altogether?

Anti-Ultimate commented 7 years ago

I don't know. I'm just compiling it on Ubuntu 14.04.

My best guess is that it's needed for network (Netplay), so it can't be dropped. There's also some other issues on Fedora, which needs libssl and libcrypto, see https://www.reddit.com/r/linux_gaming/comments/5qcbqd/dolphin_emulator_appimage_update/dczb45y/

probonopd commented 7 years ago

Yes, I'd ideally prefer to keep these out of AppImages and use what is provided by the system. Kerberos is often compiled into ibcurl even though almost no one needs or uses it, and libcurl could be built without Kerberos support which would remove a lot of unneeded dependencies.

probonopd commented 7 years ago

in https://github.com/SuperTux/supertux/issues/648#issuecomment-277527937 @maxteufel writes:

@probonopd Also, the libkrb5.so.26 being in the blacklist will cause breakage on distros that don't provide a libkrb5.so.26 (Arch Linux ships libkrb5.so.3 only), unless you relink to libkrb5.so.

Clearly there is something about Kerberos that makes distros use crazy library version numbers that increase cross-distro breakage. And as most people don't actually use Kerberos, I'd prefer a solution to remove the dependency on it. Could we write a dummy library that would resolve all the symbols in a library with the same name, and just do nothing?

lurch commented 7 years ago

Could we write a dummy library that would resolve all the symbols in a library with the same name, and just do nothing?

I wonder if https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/ could be used to do something similar "automatically" ?

probonopd commented 7 years ago

@lurch don't think we need to LD_PRELOAD, having replacement "dummy" libraries that resolve all the Kerberos symbols and no nothing might be sufficient. I don't know how to make a "dummy" library that resolves all symbols easily though.

lurch commented 7 years ago

I think I was referring more to using LD_PRELOAD to patch the dynamic linker itself (if such a thing is possible) such that missing libraries / symbols that aren't available in the system libraries simply get replaced with do-nothing stubs, rather than emitting library/symbol-not-found errors. But perhaps that would be too much of a catch-all scenario, and would lead to program crashes etc.

TBH I don't know much about libraries, linkers, AppImages, etc. so my comments should be taken with a large pinch of salt.

I wondered if you could convert the dynamically-linked ELFs to static binaries, but found this webpage that says static binaries often won't work. But maybe some of the other info on there will be useful? *shrug* (even though it's likely to be out of date)

probonopd commented 7 years ago

ld-linux.so itself is not a dynamic library. But I guess one could ship our own ld-linux.so loader inside each AppImage, and patch that... not sure we want to go down that route, though.

Anti-Ultimate commented 7 years ago

If you patch out Kerberos from libcurl, there'd be no reason to blacklist it, since it's not going to be linked anyways.

Just remove it from the blacklist.

probonopd commented 7 years ago

Will be done once we really patch out Kerberos. So far it's in preparation.