Coming from MacOS, I feel like at home with AppImage! However, I feel there’s one topic not covered in the documentation: recommended procedures for building binaries compatible with several distributions. I know this may require bundling shared libraries, or even statically linking some libraries, but still, it would be very useful to know that “if you follow these steps, your binary should run in Ubuntu, Mint, etc, for releases equal or greater than XX.YY”, for example.
1 Like
Hi @cesss and welcome to AppImage 
Check https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages, especially the examples linked there.
The key to universal AppImages is to build on the oldest build system on which your application can still be built, e.g. debian oldstable or CentOS 6 or something like that, and bundle everything that cannot be expected to be part of each target system in a recent enough version.
Let’s know here if you have further questions, or share the examples you find difficult.
Yes, I’ve read that, but it seems to be targeted to distro-dependent appimages. Instead, I wish some procedure that would allow me to create a single appimage for most distributions.
For example, if you go to the Blender download page, you’ll see they’re offering just one Linux binary (well, actually two: one for 32 and another for 64 bit) with a quick note that says “Requires glibc 2.11. Suits most recent GNU/Linux distributions”
A note as simple as that would be my wish for distributing appimages.
So, my question is, what procedure could I follow to build binaries so that my appimages can be easily distributed to “most distributions”, just like Blender (and other packages) do.
EDIT: I thought the link you gave me was another page I visited yesterday that shows examples of creating an AppImage for common applications, but that didn’t explain the problem of supporting multiple distributions. However, the link in your message does give hints at how to achieve multi-distribution binaries. Perhaps not a failsafe procedure, but following such hints and testing with some virtual machines of a few Linux distributions, I think it can be achieved.
All instructions there are meant to “create a single appimage for most distributions”. I always encourage people to build AppImages that run on more than just one distribution.
1 Like
Yes, it’s clear now. Thanks a lot.
There is a great article about creating a multi-distro package: https://joeyh.name/blog/entry/completely_linux_distribution-independent_packaging/
The key idea: you need all the dependencies (even runtime linker) to be bundled into a single directory with some wrappers around all the executables.
And this directory can be easily packaged with AppImage.
Thanks a lot. Very interesting. BTW, has anybody seen any project or instructions for building multi-distro executables from a current updated distribution, and without using a virtual machine? I guess it must be possible to have something like a sort of SDK (with old headers and libs) inside some directory and make your compiler and linker use stuff only from that “SDK” path.
I think this could be more convenient than setting up a virtual machine with an old distro. Have you seen this done, or at least attempted?
Thanks, I’ll post there, then.
I think the problem is to know which is the oldest distro and that is why testing is essential to truly verify it works. Such testing could still be costly.
I think what is generally meant is the most conservative distro which was slow of uplifting kernel, libs and susbsystems and that is not necessary measured in time. I think it would be much easier if some profile could be specified during packaging/building. Like “any distro with 2.6 kernel”. Or distros which are LSB 4.0 compliance.