Bug: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found

[terefang]

Bug report

just updated sdkman via cli today (2023-06-08) and now get the following error:

/****/.sdkman/libexec/help: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /****/.sdkman/libexec/help)

To reproduce

On Linux Mint 19.3 install/update sdkman

System info

$ uname -a
Linux oni 5.4.0-146-generic sdkman/sdkman-cli#163~18.04.1-Ubuntu SMP Mon Mar 20 15:02:59 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description:    Linux Mint 19.3 Tricia
Release:        19.3
Codename:       tricia

$ sdk version
/home/fredo/.sdkman/libexec/version: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/fredo/.sdkman/libexec/version)

$ cat /****/.sdkman/var/version
5.18.1

$ cat /****/.sdkman/var/version_native 
0.1.3

Resolution Proposal

do a static link of your binaries against musl to make them distro/version agnostic.

[terefang]

update

i cleared out the .sdkman directory and reinstalled sdkman as per usual instructions ... still same error.

 $ sdk version
/****/.sdkman/libexec/version: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /****/.sdkman/libexec/version)

$ cat .sdkman/var/version
5.18.1

$ cat .sdkman/var/version_native
0.2.9

[michelzanini]

I have the same error when installing SDKMAN on the latest version of a fresh Amazon Linux 2 AMI.

/opt/sdkman/libexec/default: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /opt/sdkman/libexec/default)
/opt/sdkman/libexec/default: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /opt/sdkman/libexec/default)

[michelzanini]

After installing and calling sdk default java ... it fails with the message above.

[michelzanini]

I have re-install SDK man using the fresh Amazon Linux 2 image again, but this time overriding this:

export SDKMAN_NATIVE_VERSION="0.2.9"

From 0.3.3 (latest) to older 0.2.9.

NOW its working!

This is definitely a bug on latest versions @marc0der. Do we need to create another ticket somewhere?
Can this be fixed. It is a critical bug if you can't install it on a normal linux....

[cnglen]

same error:

$ sdk help
~/.sdkman/libexec/help: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ~/.sdkman/libexec/help)

~/.sdkman/libexec/help: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ~/.sdkman/libexec/help)

[marc0der]

Hi all, I'll look into this as a matter of urgency.

@michelzanini I really don't see how exporting that env var could make any difference as this is a glibc linking problem of the native binaries.

Also worth mentioning that I use this on my Arch Linux dev laptop (a normal Linux) every day and have no such issues. In addition, it also runs perfectly in our CI pipeline.

That said, it definitely needs to be fixed. As a quick workaround, you can remove all files under .sdkman/libexec to fall back on the legacy bash subcommands.

[michelzanini]

I really don't see how exporting that env var could make any difference as this is a glibc linking problem of the native binaries.

Sorry, I think I didn't explain very well. I meant that I downloaded the installation script file at https://get.sdkman.io. Then modified the line where export SDKMAN_NATIVE_VERSION is and run the script from there, with version 0.2.9. From 0.3.0 and above, I get the error.

Also worth mentioning that I use this on my Arch Linux dev laptop (a normal Linux) every day and have no such issues. In addition, it also runs perfectly in our CI pipeline.

It depends on which version of CGLIB you have. The error for me is because Amazon Linux uses 2.26. If your linux is 2.28 or above, you won't get the error. There's a command to check the version of CGLIB, I believe is ldd --version, but not 100% sure.

[sureshg]

Recently started seeing similar issue (Oracle Linux 7.9, ARM A1 machine)

$ sdk version
/home/opc/.sdkman/libexec/version: relocation error: /home/opc/.sdkman/libexec/version: symbol __cxa_thread_atexit_impl, version GLIBC_2.18 not defined in file libc.so.6 with link time reference


$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="7.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"

$ uname -a
Linux xxx-a1-flex 5.4.17-2136.321.4.el7uek.aarch64 #2 SMP Mon Jun 26 16:27:14 PDT 2023 aarch64 aarch64 aarch64 GNU/Linux

[marc0der]

So I went digging and found some conclusive results:
We build our native binaries in a matrix build using docker containers. As you will see, we currently use Ubuntu LTS 20.04, which ships with GLIBC 2.31. That means that our binaries on any Linux with GLIBC below 2.31 will break. The current release version of GLIBC is at 2.38, so we are catching the majority of modern Linux distros.

Here is a table of a bunch of debian based distros and their corresponding GLIBC versions:

Distro	GLIBC
Ubuntu 16.04	2.23
Ubuntu 18.04	2.27
Ubuntu 20.04	2.31
Debian Stretch (7)	2.17
Debian Stretch (8)	2.19
Debian Stretch (9)	2.24
Debian Buster (10)	2.28
Debian Bullseye (11)	2.31
Debian Bookworm (12)	2.36
Amazon Linux 1	2.17
Amazon Linux 2	2.26
Amazon Linux 2023	2.34

Based on these findings, I would suggest the following:
Consider upgrading your Linux if you are really running with such an ancient distro that ships with GLIBC 2.17! There aren't many options available to us here, as GitHub doesn't ship any runner images older than Ubuntu 20.04.

I'm happy for any suggestions to resolve this issue. For now, all I can suggest is to upgrade. Otherwise, I will consider a feature flag that will ignore the native binaries and fall back on the bash counterparts.

[michelzanini]

Just to be clear, the distro is not ancient. Amazon Linux 2 was the latest available until
some months ago.
Can you explain how the 0.2.9 build works and 0.3.0 doesnt? Was the CI changed at that stage?
A flag to switch off binaries would be helpful if this cant be fixed.

Thanks.

[marc0der]

Puzzled why Amazon would choose to base their Linux on such a stale version of GLIBC 🤷 Anyhow, the 2023 release has set that straight by moving to 2.34.

I have no idea why you are seeing this issue between versions. Perhaps Github did something to their runner image between our release 0.2.9 to 0.3.0. I do not know if they are using a standard Ubuntu 20.04 base.

I'll see what I can do to implement the feature switch for a dumbed-down CI bash experience.

[marc0der]

UPDATE: I looked at more alternatives and spun up a new self-hosted github runner for SDKMAN. The runner is a Centos 7 droplet on DigitalOcean (Amazon 1 is based on Centos 7 and has GLIB 2.17). I've performed a release of 0.4.0 of the native distribution, and everything seems to be working great in Docker.

@michelzanini could I please ask you to confirm if that works for you now?

@terefang also, please confirm that it solves your problem and feel free to close this issue if it does.

[terefang]

i am stumped a bit?

$ sdk version

SDKMAN 5.18.1
$ sdk update

No new candidates found at this time.

[terefang]

did the following and it works now:

$ sdk selfupdate force

Updating SDKMAN...
Installing script cli archive...
* Downloading...
######################################################################## 100,0%
* Checking archive integrity...
* Extracting archive...
* Copying archive contents...
* Cleaning up...

Installing native cli archive...
* Downloading...
######################################################################## 100,0%
* Checking archive integrity...
* Extracting archive...
* Copying archive contents...
* Cleaning up...

Updating platform file...
Updating config file...

sdkman_auto_answer=false
sdkman_insecure_ssl=false
sdkman_curl_connect_timeout=7
sdkman_curl_max_time=10
sdkman_beta_channel=false
sdkman_debug_mode=false
sdkman_colour_enable=true
sdkman_auto_env=false
sdkman_rosetta2_compatible=false
sdkman_checksum_enable=true
sdkman_selfupdate_feature=true
sdkman_auto_complete=true
sdkman_auto_update=true

Creating config file backup...


Successfully upgraded SDKMAN!

Open a new terminal to start using SDKMAN 5.18.2.

To join our BETA channel, simply follow the instructions on:

   http://sdkman.io/install

Enjoy!!!

$ sdk version

SDKMAN!
script: 5.18.2
native: 0.4.2

[terefang]

thx

[michelzanini]

UPDATE: I looked at more alternatives and spun up a new self-hosted github runner for SDKMAN. The runner is a Centos 7 droplet on DigitalOcean (Amazon 1 is based on Centos 7 and has GLIB 2.17). I've performed a release of 0.4.0 of the native distribution, and everything seems to be working great in Docker.

@michelzanini could I please ask you to confirm if that works for you now?

@terefang also, please confirm that it solves your problem and feel free to close this issue if it does.

I have tested with the latest version and its working fine on Amazon Linux 2.
Thanks!

[marc0der]

Hi folks, sadly, I need to re-open this issue. As of last week, our custom GitHub runner is no longer working due to GitHub forcefully bumping all runners to use Node 20, pushing the glibc dependency to a higher version. I have yet to do a deep dive to see the fallout, but it does mean that subsequent versions of the SDKMAN native extensions will depend on a higher version than 2.17.

I thought I'd mention it here so that people can begin migrating to later versions of Amazon Linux in preparation for these changes.