Repository navigation
Make AppImages run on Alpine #1015
Description
Activity
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.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.
CC #877
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).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.The problem with glibc is that we need the right
ld-linuxas 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.
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)
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 🙂.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).
Reacted by probonopd, cakiwi and awkwardsed@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.
Reacted by Chloé Vulquin and awkwardsedI've started a draft, comments welcome: https://github.com/TheAssassin/type3-runtime
(Please continue the discussion there, here it's off topic.)
Reacted by Chloé Vulquin, Nayden Pendov and awkwardsedI 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).
- added 2 commits that reference this issue
on Jun 10, 2020 9 remaining items
xproot@cedric:~/AppImages$ ./browservice-v0.9.2.2-aarch64.AppImage bash: ./browservice-v0.9.2.2-aarch64.AppImage: No such file or directory xproot@cedric:~/AppImages$ ls browservice-v0.9.2.2-aarch64.AppImageIs this like a well known alpine issue?
xproot@cedric:~/AppImages$ ./browservice-v0.9.2.2-aarch64.AppImage bash: ./browservice-v0.9.2.2-aarch64.AppImage: No such file or directory xproot@cedric:~/AppImages$ ls browservice-v0.9.2.2-aarch64.AppImageIs this like a well known alpine issue?
This is a well known linux issue.
Exec failures are reported this way.
Usually, it's a consequence of wrong architecture or missing libraries/symbols - normally you'd try running it throughfile(1)andldd(1).However, in this case, it's likely using the original stub, which dynamically links to glibc (which is obviously not present), which is indeed what this (unresolved, unlikely to be resolved) bug is about.
Similarly, you would find running musl-dynlinked binaries a challenge on a glibc distribution without installing musl.Reacted by Viacheslav Moskin and Antoxproot@cedric:~/AppImages$ ./browservice-v0.9.2.2-aarch64.AppImage bash: ./browservice-v0.9.2.2-aarch64.AppImage: No such file or directory xproot@cedric:~/AppImages$ ls browservice-v0.9.2.2-aarch64.AppImageIs this like a well known alpine issue?
I get this when not using gcompat. Using gcompat i get the error shown above.
- added 2 commits that reference this issue
on Jan 28, 2022 I've also opened https://git.adelielinux.org/adelie/gcompat/-/issues/349 for this.
If I understand it right, it Looks like https://github.com/eth-cscs/spack-batteries-included is providing a solution for this. Should we backport these changes into the AppImage runtime?
Differences and improvements over AppImage runtime
spack.x uses zstd for faster decompression;
spack.x itself is an entirely static binary;
spack.x does not need to dlopen libfuse.soReference:
#1120 (comment)
cc @haampieReacted by Alejandro González and Jordan ChristiansenI believe the AppImages from https://github.com/probonopd/go-appimage/releases/tag/continuous which are using the experimental static runtime might work on Alpine (if fusermount is installed and the fuse kernel module is loaded) but I fail to get DHCP and internet access running when booting into
https://dl-cdn.alpinelinux.org/alpine/v3.12/releases/x86_64/alpine-standard-3.12.0-x86_64.iso
Does anyone know how to test this?
On v3.12,
setup-interfaces, press enter a few times for defaults, andservice networking restart. Onnewer Alpine versionsv3.15 or later, you can just dosetup-interfaces -r.Also, you may want to setup repositories:
setup-apkrepos -1, and (if desired) uncomment community in/etc/apk/repositoriesthenapk update.Reacted by probonopdAnd
appimagetoolfrom your first link does run on my Alpine edge system.Reacted by probonopdReacted by probonopdReacted by probonopd and benpietrasDiscussion continues in
If I understand it right, it Looks like https://github.com/eth-cscs/spack-batteries-included is providing a solution for this. Should we backport these changes into the AppImage runtime?
Differences and improvements over AppImage runtime
spack.x uses zstd for faster decompression;
spack.x itself is an entirely static binary;
spack.x does not need to dlopen libfuse.soReference: #1120 (comment) cc @haampie
It uses the same method as flatpaks, runtimes contain a small Linux system... In this case, it contains gtar, python3, binutils and other misc programs and libraries that were compiled against glibc but then modified to link against a local glibc (a glibc installed inside of the runtime)
If only the guides for packaging AppImages told developers to ALWAYS TRY to statically link using musl-gcc or an Alpine container or install... AppImages would be smaller and would be actually portable.
Reacted by SolidLamp and CraftEverything has upsides and downsides. But yes, I like the approach you suggest.
Alpine has
libc6-compatwhich provides ld-linux, so in theory it should run there, but in practice we are getting: