Appimagekit: Make AppImages run on Alpine

[probonopd]

Alpine has libc6-compat which provides ld-linux, so _in theory_ it should run there, but _in practice_ we are getting:

/patchelf-0.10 # apk add libc6-compat
(1/1) Installing libc6-compat (1.1.22-r3)
OK
/patchelf-0.10 # ./appimagetool-390-x86_64.AppImage 
Error relocating ./appimagetool-390-x86_64.AppImage: gnu_dev_makedev: symbol not found

[probonopd]

Documentation says:

Conforming to
The makedev(), major(), and minor() functions are not specified in POSIX.1, but are present on many other systems.
Notes
These interfaces are defined as macros. Since glibc 2.3.3, they have been aliases for three GNU-specific functions: gnu_dev_makedev(), gnu_dev_major(), and gnu_dev_minor(). The latter names are exported, but the traditional names are more portable.

[TheAssassin]

Would a statically linked binary (e.g., using musl internally) work on every system? Can we safely assume that? I mean, we have a dependency on FUSE, but that's more API than ABI, and any FUSE client should be able to talk to any distro, no matter what libc they use.

[TheAssassin]

CC #877

[CosmicToast]

There is a library named libgcompat that provides most of the additional (non-standard) features in glibc for musl-based systems.
When I was trying to do some fairly specific stuff it got me a bit further in the process (ncurses would act weird), but it should be most of the solution here - https://code.foxkit.us/adelie/gcompat
(There's also a GitHub mirror)

I think the optimal solution will eventually be to build things against musl (ideally statically) and package all the deps in the appimage.
That way it'll even run on "older" distributions, and has less of an associated cost (due to the size and scope of musl and co.).
Appimages will always take up more space than "native" counterparts, but it makes up for it immensely using everything it brings in - leaning into that aspect seems natural, especially given how cheap storage is, relative to everything else (within reasonable bounds, but I do encourage commenters to-be to look at their filesystem usage patterns).

[CosmicToast]

Would a statically linked binary (e.g., using musl internally) work on every system? Can we safely assume that?

That's a fairly safe assumption. ABI incompatibilities are a thing, as well as kernel headers, but I've done some fairly extreme things in the past (such as statically linked shells and utilities for use in a system that hasn't been updated in about a decade).
Musl allowing true static linking is very important relative to glibc in that use-cases.

[TheAssassin]

The problem with glibc is that we need the right ld-linux as linker, too, right? I don't know exactly how musl works in detail.

I think we need to finally extract and separate the runtime from the rest of the code, then we can create the regular builds with their semi-static linking and also experiment with truly static runtime builds.

[probonopd]

Some instinct tells me that sooner or later we'll end up making the runtime a version of ld-linux, so that it doesn't have to rely on one from the system... (musl's is even MIT licensed)

[CosmicToast]

The problem with glibc is that we need the right ld-linux as linker, too, right? I don't know exactly how musl works in detail.

That gcompat project I mentioned provides a linker (compatibility stub*) too, but yes, that's part of it.

I think we need to finally extract and separate the runtime from the rest of the code, then we can create the regular builds with their semi-static linking and also experiment with truly static runtime builds.
Some instinct tells me that sooner or later we'll end up making the runtime a version of ld-linux, so that it doesn't have to rely on one from the system... (musl's is even MIT licensed)

Both of these sound interesting.
Also, consider me available for general help (pings and such) - I believe the general concept of AppImages to be the best way for general linux distribution, for a variety of reasons.
I'm also a maintainer of a few packages on Alpine Linux and the co-founder of Abyss OS - in which we plan to use the general AppImage idea (not necessarily the main implementation, it's a bit early to decide on that) to distribute most user-facing applications (by way of packaging them ourselves), so I'm somewhat invested as it is :slightly_smiling_face:.

I'm fairly busy, but knowing where and what to poke at to understand the codebase would be useful as well, if possible (as much as I abhor C).

[TheAssassin]

@5paceToast thanks for your offer. We've already found enough reasons to make a AppImage type 3, in which we intend to solve a lot of problems. Your input will be welcome.

[TheAssassin]

I've started a draft, comments welcome: https://github.com/TheAssassin/type3-runtime

(Please continue the discussion there, here it's off topic.)

[probonopd]

I don't think we need a new type in order to address the points mentioned in this thread; this imho all can be achieved by a new _runtime_ for type 2 images (i.e., a squashfs or other filesystem appended to an ELF binary).

[wenerme]

About one year now, any progress here to support musl ?

[probonopd]

Looks like no one is working on it.

[vinniec]

Has anyone tried with this? https://github.com/sgerrand/alpine-pkg-glibc
I tried without a positive result but I actually don't know if it should have worked or not.

[anki-code]

Hi @vinniec! Thank you for the link. Yes! It works!

I've made a test with the xonsh shell and report the successfull result - https://github.com/sgerrand/alpine-pkg-glibc/issues/153#issuecomment-795334536