AppImage is not what you need. It's just an executable wrapper for the archive. To make the software cross-distro, you need to compile it manually on an old distro with old glibc, make sure all the dependencies are there, and so on.

https://docs.appimage.org/reference/best-practices.html#bina...

There are several automation tools to make AppImages, but they won't magically allow you to compile on the latest Fedora and expect your executable to work on Debian Stable. It's still require quite a lot of manual labor.

Yeah a lot of Appimage developers make assumptions about what their systems have as well (i.e. "if I depend on something that is installed by default on Ubuntu desktop then it's fine to leave out"). For example, a while ago I installed an Appimage GUI program on a headless server that I wanted to use via X11 forwarding. I ended up having to manually install a bunch of random packages (GTK stuff, fonts, etc) to get it to run. I see Appimage as basically the same as distributing Linux binaries via .tar.gz archives, except everything's in a single file.

Don't forget - AppImage won't work if you package something with glibc, but run on musl/uclibc.

>I wonder though, if I package say a .so file from nVidia, is that allowed by the license?

It won't work: drivers usually require exact (or more-or-less the same) kernel module version. That's why you need to explicitly exclude graphics libraries from being packaged into AppImage. This make it non-runnable on musl if you're trying to run it on glibc.

https://github.com/Zaraka/pkg2appimage/blob/master/excludeli...

No, that's a copyright violation, and it won't run on AMD or Intel GPUs, or kernels with a different Nvidia driver version.

But this ruins the entire idea of packaging software in a self-contained way, at least for a large class of programs.

It makes me wonder, does the OS still take its job of hardware abstraction seriously these days?

The OS does. Nvidia doesn't.

Does Nvidia not support OpenGL?

Not really. Nvidia-OpenGL is incompatible to all existing OS OpenGL interfaces, so you need to ship a separate libGL.so if you want to run on Nvidia. In some cases you even need separate binaries, because if you dynamically link against Nvidia's libGL.so, it won't run with any other libGL.so. Sometimes also vice versa.

Does AMD use a statically linked OpenGL?

AMD uses the dynamically linked system libGL.so, usually Mesa.

So you still need dynamic linking to load the right driver for your graphics card.

Most stuff like that uses some kind of "icd" mechanism that does 'dlopen' on the vendor-specific parts of the library. Afaik neither OpenGL nor Vulkan nor OpenCL are usable without at least dlopen, if not full dynamic linking.

It does, and one way it does that is by dynamically loading the right driver code for your hardware.

That’s a licensing problem not a packaging problem. A DLL is a DLL - only thing that changes is whether you’re allowed redistribute it

Typically appimage packaging excludes the .so files that are expected to be provided by the base distro.

Any .so from nvidia is supposed to be one of those things. Because it also depends on the drivers etc.. provided by nvidia.

Also on a side note, a lot of .so files also depends on other files in /usr/share , /etc etc...

I recommend using an AppImage only for the happy path application frameworks they support (eg. Qt, Electron etc...). Otherwise you'd have to manually verify all the libraries you're bundling will work on your user's distros.

Depends on the license and the specific piece of software. Redistribution of commercial software is may be restricted or require explicit approval.

You generally still also have to abide by license obligations for OSS too, e. G., GPL.

To be specific for the exampls, Nvidia has historically been quite restrictive (only on approval) here. Firmware has only recently been opened up a bit and drivers continue to be an issue iirc.