Open xaljer opened 2 months ago
You can build the appimage yourself using tools like this for example.
There is this appimagetool which has a deploy everything mode that bundles glibc in the appimage that makes the appimage be able to run in any distro, be it very old distros or even musl distros. It also uses a static runtime which prevents the no libfuse2 issues in newer distros.
I just tested converting the existing appimage by extracting it and then running ./appimagetool -s deploy squashfs-root/usr/share/applications/Helix.desktop
followed by ARCH=x86_64 VERSION=test ./appimagetool -s squashfs-root
and it works (new size is 30 MiB btw), it is possible that deploying everything might introduce a bug though.
Ideally you would build with a statically linked musl and then deploy everything.
Yes, can we please get a binary in the Releases page that would allow me to just download it and run it on any old linux system? I'm on an unfamiliar machine right now without many permissions. I'd love to just wget the hx binary and start using it but I'm getting the message that glibc is too old. I've been totally spoiled by Go and assume everything can just be a single binary that just works. ðŸ˜
I just made what I think are the necessary changes
However how do you start the CI here so that I can verify that everything builds correctly? I don't want to make the PR without testing
I'm not sure we want this. https://github.com/helix-editor/helix/issues/1932#issuecomment-1572155314
But this up to a maintainer to review to decide if that still stands.
I'm not sure we want this. #1932 (comment)
But this up to a maintainer to review to decide if that still stands.
In this case you are not actually supporting an old version of glibc, you are simply bundling the glibc of the CI into the appimage, which for all purpose has the same result as the appimage being able to run in very old distributions and has the plus that it can also run in musl distributions as well.
I already linked the diff above showing the needed changes, in any case you don't want to maintain that let me know so I can setup a repo that builds said appimage for the people that need it.
If you make a PR that changes the release.yml workflow it will trigger a dryrun release. You can open up a draft PR and inspect the outputs. If it doesn't add too much time to the workflow and doesn't bloat the appimage itself too much I think it's ok to add this
Artifact for testing: https://github.com/helix-editor/helix/actions/runs/10031937785/artifacts/1726338025
edit: $HELIX_RUNTIME
was unset, I just fixed it and will update the link once the workflow is approved.
Updated artifact: https://github.com/helix-editor/helix/actions/runs/10049369085/artifacts/1728836018
The appimage with a bundled glibc is the one that contains anylinux
in the zip file.
If your distribution has /bin
and /usr/bin
separated (which is common on very old distros) you might need to launch the appimage with FUSERMOUNT_PROG=/bin/fusermount ./Helix-dev-anylinux-x86_64.AppImage
or just make a symlink to fusermount in /usr/bin
if you have sudo access.
Oddly enough the size increase ended up being less than 1 MiB with bundled glibc in the anylinux appimage.
I want to try helix on Ubuntu 20.04, but glibc version is too low. It would be better if providing a self contained version of appimage.