Open Anti-Ultimate opened 7 years ago
This is the final script which made a AppImage on Ubuntu 14.04 that works on an Antergos LiveCD
Thanks @Anti-Ultimate
Hardly anyone ever actually uses Kerberos, so maybe it could best be patched away altogether?
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/
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.
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?
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" ?
@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.
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)
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.
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.
Will be done once we really patch out Kerberos. So far it's in preparation.
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.