Feat: support GLIB 2.28 #1932
Comments
|
We just build against whatever glibc is available on the CI, 2.28 is a few years out of date by now. What type of packaging does RHEL use, could you use the Fedora package? |
|
RHEL uses RPM, Fedora packages are also RPM but won't work unless they are very old. RHEL 8 was based on Fedora 28. If you could somehow tell your CI to use If you want to go next level with automatic Linux packaging, some projects are using the free openSUSE Build Service, for example nnn : https://software.opensuse.org//download.html?project=home%3Astig124%3Annn&package=nnn . It supports Fedora, Debian, Ubuntu, RHEL and more out of the box. I have not used it myself to build anything, but it seems to work very well for the packages I have used from it. It provides a repo so that users can update with their own package manger, for example to install After that you are set, updates are automaticity handled by your package manager :) |
|
+1 |
|
It looks like someone has been working on 22.03 for OBS recently: https://build.opensuse.org/package/show/home:dancermak:branches:home:exprss77/Helix If you'd like to set one of these up, feel free! Most of the packaging like this is done by community effort (for example the COPR or AUR packages). It's not clear to me that OBS would solve the glibc version problem though - would it? In general, I would prefer to see specific packaging like this live in an OS-level package manager rather than be part of the release phase, especially because the release phase relies on whatever runners and versions GitHub Actions makes available to us. |
Cool. I am going to keep my eye on that. The author is a SUSE employee so will know what he is doing. If that builds OK maybe we can try and use his spec file to build for other distributions.
I think it would, it should build for each distribution you select intelligently. |
kirawi
added
C-enhancement
|
I had the same issue with delta and try out there musl build (https://github.com/dandavison/delta/releases/download/0.12.1/delta-0.12.1-x86_64-unknown-linux-musl.tar.gz) and it works so if you could add the build target to the release would be great: x86_64-unknown-linux-musl |
Yes, I had the same thing too, the musl build worked. |
|
#2089 Appimage is ready to merge! I am hoping that solves the GLIB issue, the script was converted from Neovim and those Appimages work fine. |
|
W.r.t. a musl artifact: delta is just running on ubuntu-latest and cross-compiling to musl: https://github.com/dandavison/delta/blob/3ccf2bc8d26b9296a08110d9ac7bc60d86bbeaa6/.github/workflows/cd.yml#L18. We could probably do very similarly with a block similar to this one: helix/.github/workflows/release.yml Lines 69 to 73 in 893963d |
|
i got the same issue using WSL2 with debian on windows 11 |
I tried the AppImage and it has the same issue: |
|
I just wanted to add that I did a musl build and syntax highlight did not worked. So then I tried to do a build using the buster docker image and this does work as expected. So maybe if we use buster image instead of ubuntu might solve the issue. |
|
when running
helix-editor version: 22.05
Sorry for images, this is from a server with no copy-paste access |
|
Four months after I originally made this feature request I don't want it anymore, now RHEL / Rocky / Alma 9 is out we have Redhat enterprise Linux on If other people still want it then thumbs up this comment otherwise I will close the issue. |
|
@David-Else I've enabled EPEL 9 on COPR too by the way! 😃 |
|
@VarLad Thanks for the EPEL 9 support! I had a quick look at the COPR using liveuser on a Fedora 36 ISO and it did not seem to install the desktop file or the new icon from https://github.com/helix-editor/helix/tree/master/contrib using something along the lines of https://github.com/helix-editor/helix#adding-helix-to-your-desktop-environment? Or maybe I need a full install from hard drive to get desktop integration? |
|
@David-Else Haven't included desktop file yet since I assumed most will open it from their preferred terminal |
|
Tried with appimage 22.12 on Ubuntu 18.04 and got: |
|
Support of GLIBC_2.28 would indeed be nice to be able to run it on CentOS 8. There is a workaround. You can compile a newer glibc yourself and use patchelf to fix all helix binary releases afterwards. Get some coffee and then compile a more recent version of glibc: GLIBC_VERSION='2.34'
# Location where you want to store new glibc.
GLIBC_PARENT_DIR='/software/glibc'
# GLIBC_PARENT_DIR="${PWD}" # (or cd to directory of choice and execute this)
mkdir -p "${GLIBC_PARENT_DIR}"
cd "${GLIBC_PARENT_DIR}"
# Download Glibc source code.
wget "https://ftp.gnu.org/gnu/glibc/glibc-${GLIBC_VERSION}.tar.xz"
# Untar.
tar xJf glibc-${GLIBC_VERSION}.tar.xz
# Make some dirs.
mkdir glibc-${GLIBC_VERSION}-build glibc-${GLIBC_VERSION}-install
cd "${GLIBC_PARENT_DIR}/glibc-${GLIBC_VERSION}-build"
# Configure glibc.
../glibc-${GLIBC_VERSION}/configure --prefix /"${GLIBC_PARENT_DIR}/glibc-${GLIBC_VERSION}-install"
# Build glibc.
make -j 8
# Install glibc.
make installFix # Backup a copy of the helix binary, just in case something goes wrong.
cp -a /software/helix/helix-22.12-x86_64-linux/hx /software/helix/helix-22.12-x86_64-linux/hx_original
# Set GLIBC variables correctly (as above):
GLIBC_VERSION='2.34'
GLIBC_PARENT_DIR='/software/glibc'
# Install
patchelf \
--set-interpreter "${GLIBC_PARENT_DIR}/glibc-${GLIBC_VERSION}-install/lib/ld-linux-x86-64.so.2" \
--add-rpath "${GLIBC_PARENT_DIR}/glibc-${GLIBC_VERSION}-install/lib" \
/software/helix/helix-22.12-x86_64-linux/hx
# Enjoy.
$ /software/helix/helix-22.12-x86_64-linux/hx -h
helix-term 22.12 (96ff64a8)
Blaž Hrastnik <blaz@mxxn.io>
A post-modern text editor.
USAGE:
hx [FLAGS] [files]...
ARGS:
<files>... Sets the input file to use, position can also be specified via file[:row[:col]]
FLAGS:
-h, --help Prints help information
--tutor Loads the tutorial
--health [CATEGORY] Checks for potential errors in editor setup
CATEGORY can be a language or one of 'clipboard', 'languages'
or 'all'. 'all' is the default if not specified.
-g, --grammar {fetch|build} Fetches or builds tree-sitter grammars listed in languages.toml
-c, --config <file> Specifies a file to use for configuration
-v Increases logging verbosity each use for up to 3 times
--log Specifies a file to use for logging
(default file: /data/leuven/303/vsc30366/.cache/helix/helix.log)
-V, --version Prints version information
--vsplit Splits all given files vertically into different windows
--hsplit Splits all given files horizontally into different windows |
|
FYI the latest (23.03) release's provided binaries no longer work on Debian 11 due to a newer linked > cat /etc/os-release | head -n3
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
> ldd --version | head -n1
ldd (Debian GLIBC 2.31-13+deb11u5) 2.31
> ./helix-23.03-x86_64.AppImage
/tmp/.mount_helix-mojgg3/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_helix-mojgg3/usr/bin/hx)
/tmp/.mount_helix-mojgg3/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /tmp/.mount_helix-mojgg3/usr/bin/hx)
/tmp/.mount_helix-mojgg3/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/.mount_helix-mojgg3/usr/bin/hx)
> ./helix-23.03-x86_64-linux/hx --version
./helix-23.03-x86_64-linux/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./helix-23.03-x86_64-linux/hx)
./helix-23.03-x86_64-linux/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./helix-23.03-x86_64-linux/hx)
./helix-23.03-x86_64-linux/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./helix-23.03-x86_64-linux/hx)At least for AppImage, is it possible to ship it with the version of |
Same here. Debian 11, bulleye, is the last stable and shipped with GLIBC_2.31. |
|
Here is a workaround, inspired by this: within hx folder: wget http://ftp.de.debian.org/debian/pool/main/g/glibc/libc6-amd64_2.36-8_i386.deb
dpkg-deb -x libc6-amd64_2.36-8_i386.deb libc6
patchelf --set-interpreter $(realpath libc6/lib64/ld-linux-x86-64.so.2) --set-rpath $(realpath libc6/lib64/) hxThis will patch hx binary to link to a local glic v2.36. And it works. |
|
same issue with Ubuntu 20.04.1 LTS, as originally reported by @joncfoo : $ ldd --version | head -n1
ldd (Ubuntu GLIBC 2.31-0ubuntu9.9) 2.31$ ./helix-23.03-x86_64.AppImage
/tmp/.mount_helix-gn3qvY/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_helix-gn3qvY/usr/bin/hx)
/tmp/.mount_helix-gn3qvY/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /tmp/.mount_helix-gn3qvY/usr/bin/hx)
/tmp/.mount_helix-gn3qvY/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/.mount_helix-gn3qvY/usr/bin/hx) |
There seems to be no link with the current issue. |
|
FYI - same problem with helix-23.03-x86_64.AppImage on OpenSuse Leap 15.4 This is the output from Helix: _tmp/.mount_helix-BDoqE8/usr/bin/hx: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_helix-BDoqE8/usr/bin/hx) /tmp/.mount_helix-BDoqE8/usr/bin/hx: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /tmp/.mount_helix-BDoqE8/usr/bin/hx) /tmp/.mount_helix-BDoqE8/usr/bin/hx: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/.mount_helix-BDoqE8/usr/bin/hx)_ I'll try to locally compile the source to get around the problem. Update: The local compile worked and after linking the runtime directory, Helix functions great. Thanks for all the great work on this editor! |
|
Add static compile link with musl instead of glibc? |
|
After I static compiled the hx with musl, I found all of the languages could not be highlighted. hx load the dynamic library. The dynamic library cannot load the libc.so correctly. Any plan about static link the tree sitter? |
|
I wrapped up a customizable helix builder through docker. Default target is GLIBC version 2.31. |
|
I'm hitting this with only glibc 2.26 available on Amazon Linux 2 in a remote development environment via the Amazon Workspaces product. |
Gotta love adademic clusters - Top modern GPUs (h100s), but damn it if the software isn't infuriating. I already got a ticket with them about issues using enroot, where I didnt hear back until about 2 months later, so even if I had the energy to ask for an upgrade I probably wouldnt get anywhere, I'm just a student after all. |
|
This reminds me of python's manylinux, they deliberately build C extension on very old linux to workaround the glibc version problem... |
|
So I got a helix v23.05 manylinux variant build hosted at https://github.com/cloudhan/helix/releases/tag/23.05-manylinux by hacking github actions to run with pypa manylinux2014 docker image. |
|
@cloudhan Thank you very much! Before I use this on my cluster I felt I had to check that there's nothing nefarious going on - AFAICT there isnt -, but in the process I saw a few disclaimers of github: I also saw the adjustments you had to make because of Now, AFAICT these Github warnings probably are because youve only pushed your tag to github, and not the branch you developed it on. And I can very much see most adjustments youve made in commit Is there a reason you didn't push the source branch? Because If it was an mistake, perhaps just do that, and then you would probably be able to revert the changes because of ownership you've made in the above commit. If you've made them on the master branch and didn't want to push that, just create a new branch based on your master and push that, and then |
|
This is a POC that we can solve this problem by simply reusing pypa manylinux strategy, and serve as a reference for helix core devs. The fork will not be long term maintained. So pls do not rely on it. @archseer How do you think manylinux solution, IMHO, it will eliminate a lot of long term compatability problem. |
|
I just don't think this is something we want to maintain. Releases are there on best effort basis for convenience, if you require something more custom you can set up builds via manylinux or just manually compile for your platform. Especially since glib 2.29 has been released four years ago at this point. |
|
@cloudhan Yeah, I mostly mentioned this since I was thankful, and I guess also because I wondered if this would actually fix it. Frankly I feel justified using this in an system where they already only provide too old software (after checking there's nothing obviously malicious), but yeah should not be recommended. @archseer Yes, I guess this sadly makes sense. Linking against such an old glibc might also be a security risk, dont really know enough. However, linking against glibc in general might be something wort to avoid. Considering you already have an appimage version. Theres a few linux distros around without gnu, instead just musl. If one were to build the Appimage in a musl environment, wouldn't that lead to a binary without any library dependencies, that should work everywhere? AFAICT issues with the musl build were already solved in the respective issues and/or were a result of missing dependencies - which the appimage would solve. |
A low effort strategy would be to use # Installl cargo-zigbuild: https://github.com/rust-cross/cargo-zigbuild
cargo install cargo-zigbuild
# Install zig:
wget https://ziglang.org/download/0.11.0/zig-linux-x86_64-0.11.0.tar.xz
sudo mkdir /opt/zig/
sudo tar xJv -C /opt/zig -f zig-linux-x86_64-0.11.0.tar.xz
# Compile helix-term and link to glib-2.17 (glibc used by CentOS7):
cd helix/helix-term
PATH=/opt/zig/zig-linux-x86_64-0.11.0:$PATH cargo zigbuild --target x86_64-unknown-linux-gnu.2.17 --release
# Glibc maximum version in helix binary:
$ strings ../target/x86_64-unknown-linux-gnu/release/hx |grep GLIBC
GLIBC_2.2.5
GLIBC_2.12
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.7
GLIBC_2.9
GLIBC_2.14
GLIBC_2.15
GLIBC_2.17
# OS glibc version.
$ ls -l /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Apr 7 2022 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so
|
|
Hello, I managed to use GitHub CI to build https://github.com/zydou/helix Update: I have also successfully compiled a |
|
I've got Helix compiling on Amazon Linux 2 with glibc 2.26. No issues during the compilation process. I'd appreciate binaries that just work, but if that's difficult, it's really no problem to compile locally. PS: rust-analyzer only supports glibc 2.27 and up so it needs to be compiled manually too. There was also no issue here. |
I tried the Linux version https://github.com/helix-editor/helix/releases/download/22.03/helix-22.03-x86_64-linux.tar.xz on Rocky Linux 8.5 (RHEL clone) and got:
Is it possible to supply a binary that works with GLIB 2.28?
EDIT: I did compile it following the instructions and it seems to be working OK, but that would be a real chore to do for every update.
The text was updated successfully, but these errors were encountered: