Feat: support GLIB 2.28

[David-Else]

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:

hx: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by hx)

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.

[archseer]

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?

[David-Else]

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 2.28 all would be well, otherwise some other solution could be used.

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 nnn on RHEL 8 (the same as Centos, Rocky, Alma, Euro Linux):

cd /etc/yum.repos.d/
wget https://download.opensuse.org/repositories/home:stig124:nnn/CentOS_8/home:stig124:nnn.repo
yum install nnn

After that you are set, updates are automaticity handled by your package manager :)

[jmtscaff]

+1

[the-mikedavis]

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.

[David-Else]

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

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.

It's not clear to me that OBS would solve the glibc version problem though - would it?

I think it would, it should build for each distribution you select intelligently.

[jmtscaff]

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

[David-Else]

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.

[David-Else]

https://github.com/helix-editor/helix/pull/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.

[the-mikedavis]

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: https://github.com/helix-editor/helix/blob/893963df0ad8596034522cd18570517f823d7123/.github/workflows/release.yml#L69-L73

[ff2400t]

i got the same issue using WSL2 with debian on windows 11

[jmtscaff]

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.

I tried the AppImage and it has the same issue:

[jmtscaff]

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. Here is the command I used to do the build:

docker run --rm --user "$(id -u)":"$(id -g)" -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust:buster cargo build --release

So maybe if we use buster image instead of ubuntu might solve the issue.

[the-mikedavis]

The missing syntax highlighting on musl: https://github.com/helix-editor/helix/issues/1028 but someone got the compilation working on https://github.com/helix-editor/helix/issues/1603

Debian Buster was 2019 which would coincide with glib 2.28. We could probably accomplish the same with an ubuntu-18.04 runner (glib 2.27).

[hamzamohdzubair]

when running appimage

helix-editor version: 22.05

Sorry for images, this is from a server with no copy-paste access

[David-Else]

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 glib 2.34

If other people still want it then thumbs up this comment otherwise I will close the issue.

[VarLad]

@David-Else I've enabled EPEL 9 on COPR too by the way! :smiley:

[David-Else]

@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?

[VarLad]

@David-Else Haven't included desktop file yet since I assumed most will open it from their preferred terminal Thanks for the input. I'll include it soon.

[mabasic]

Tried with appimage 22.12 on Ubuntu 18.04 and got:

/tmp/.mount_hx2ZB1XL/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_hx2ZB1XL/usr/bin/hx)
/tmp/.mount_hx2ZB1XL/usr/bin/hx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/.mount_hx2ZB1XL/usr/bin/hx

[ghuls]

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 install

Fix hx binary with patchelf:

# 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

[joncfoo]

FYI the latest (23.03) release's provided binaries no longer work on Debian 11 due to a newer linked glibc being used while building the releases. The previous (22.12) release's binaries worked with gblic v2.31 on Debian 11.

> 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 glibc it was built with?

[setop]

FYI the latest (23.03) release's provided binaries no longer work on Debian 11 due to a newer linked glibc being used while building the releases. The previous (22.12) release's binaries worked with gblic v2.31 on Debian 11.

Same here. Debian 11, bulleye, is the last stable and shipped with GLIBC_2.31. I was eager to install 23.03 to enjoy soft-wrap but had to rollback to 22.12 :cry:

[setop]

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/) hx

This will patch hx binary to link to a local glic v2.36.

And it works.

[lanceschi]

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)

[setop]

Perhaps this is a bug, but the Helix icon isn't showing @VarLad . I'm on Fedora 38, by the way.

There seems to be no link with the current issue.

[rlew-metastability]

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/.mounthelix-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!

[tosone]

Add static compile link with musl instead of glibc?

[tosone]

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?

[lanceschi]

I wrapped up a customizable helix builder through docker. Default target is GLIBC version 2.31. You can have a look at the repo here

[beegan]

I'm hitting this with only glibc 2.26 available on Amazon Linux 2 in a remote development environment via the Amazon Workspaces product.

[9SMTM6]

LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: RedHatEnterprise Description: Red Hat Enterprise Linux release 8.6 (Ootpa) Release: 8.6 Codename: Ootpa

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.

[cloudhan]

This reminds me of python's manylinux, they deliberately build C extension on very old linux to workaround the glibc version problem...

[cloudhan]

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.

[9SMTM6]

@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: This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

I also saw the adjustments you had to make because of fatal: detected dubious ownership in repository at ....

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 2e4edc3 also being required as a result of this.

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 git reset --hard origin/master (or `git reset --hard d511122279b3b479362830305f4812f096273b6a) while on master to be able to push/pull future master branches. I BELIEVE that should fix everything too.

[cloudhan]

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.

[archseer]

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.

[9SMTM6]

@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.

[ghuls]

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.

A low effort strategy would be to use cargo-zigbuild to build helix as zig can target older glibc version than the one used by the OS.

# 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

[zydou]

Hello, I managed to use GitHub CI to build helix on Ubuntu 16.04 (GLIBC 2.23) via Docker container.

https://github.com/zydou/helix

Update: I have also successfully compiled a musl version of helix, which doesn't rely on glibc!

[ShiromMakkad]

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.

[TheWaveLab]

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 install

Fix hx binary with patchelf:

# 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

this should be my solution, bro