Nix bundle, Nix bundle appimages - glibc questions

1

Hi - 3 situations:
1 nix bundle - resulting bundle may have glibc issue if running on a system
with incompatible glibc? I thought all Nix packages had their own glibc!
2 nix bundle --bundler github:ralismark/nix-appimage nixpkgs#$pname
will not have glibc issues because it is packaged with something called
appImage-runtime?
3 manually created (normal) AppImages can have glibc issues
(presumably not with appimage-runtime)?

Quote
‘AppImages should run on all Linux Platforms, but currently they don’t, this is because it is dynamically linked against glibc.’

Quote -
Thanks to using AppImageCrafers/appimage-runtime, the produced bundle doesn’t depend on glibc, avoiding the issue described here and meaning it should be portable to more system.

Have I got these three things right? Trying to find more about using appimage-
runtime.

Bye the bye - creating appimages from nix is working smoothly for me.
Created fish, dutree, and kde konsole appimages on a Debian 10
system and copied them to Manjaroo. Ran like a charm.

Thanks

Murray

2

Hi, author of nix-appimage here :wave:

Bundling nix apps always bundles the nix glibc required for the app, however the issue is with the appimage runtime – the program that loads and starts the bundled app. The default one relies on the system glibc. That’s normal for stuff built with nix, but means that you might have incompatibility issues running in other systems. nix-appimage instead uses an alternate appimage runtime that can use musl libc instead and be completely statically linked, avoiding any dependency on the system glibc.

Once the appimage runtime sets everything up, the actual bundled app uses the bundled interpreter and libraries, and nothing from the outside system.

Hope you answers your question!

3

Funny, over on the Void Linux subreddit, we were discussing this very problem with some AppImages not working on musl-c Void. Answer, build those app images using nix-appimage and make them more compatible!