bun
bun copied to clipboard
[Bug] bun: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by bun)
Hello,
I'm experiencing the following error on Linux Mint 19.3 :
bun: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by bun)
Thanks
Same issue on Debian, and a similar one on Alpine:
# ldd bun
/lib64/ld-linux-x86-64.so.2 (0x7fe617194000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by bun)
Error relocating bun: backtrace: symbol not found
Error relocating bun: malloc_trim: symbol not found
Error relocating bun: __cxa_thread_atexit_impl: symbol not found
Error relocating bun: __sprintf_chk: symbol not found
Error relocating bun: __strftime_l: symbol not found
Error relocating bun: __register_atfork: symbol not found
Error relocating bun: fcntl64: symbol not found
Error relocating bun: __cxa_thread_atexit_impl: symbol not found
Error relocating bun: __res_init: symbol not found
Installed using the YOLO method: curl https://bun.sh/install | bash
.
It seems the provided binaries are dynamically linked against a specific glibc version. The problem for @KaKi87 is likely that they have a different version of glibc. The problem in my case in that alpine uses musl instead of glibc.
Potential fixes for this:
- Check the glibc version on installation, and bail if there's a mismatch.
- Provide statically linked binaries. If you use glibc for this, your entire project would need to be GPLv2, so you need to use musl for these builds.
Edit: I'd mixed up results from Debian and Alpine.
@KaKi87 Same issue on WSL using Ubuntu_18.04 distribution which has glibc 2.27. Solved by installing Ubuntu 20.04 dsitribution instead which has glibc 2.31.
Can check version of glibc by running ldd --version
@KaKi87 It also happens when installing using the recommended method curl https://bun.sh/install | bash
in WSL ( Debian 11.3 Bullseye, latest version from the Microsoft Store).
Since it has Glibc 2.24:
ldd (Debian GLIBC 2.24-11+deb9u4) 2.24
And the minimum compatible is 2.25:
bun: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by bun)
bun: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by bun)
bun: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by bun)
bun: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by bun)
bun: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by bun)
You could try to install one of the compatible versions using apt, assuming you have administrative privileges:
sudo apt install libc-bin=2.29 libc6=2.29
However, it depends on the versions available in the repositories for Linux Mint. I hope this can be of help.
I have v2.27.
Why can't bun
be compatible with that ?
Linux Mint 19.3 will only be EOL in April 2023.
Thanks
Same issue on Debian, and a similar one on Alpine:
# ldd bun /lib64/ld-linux-x86-64.so.2 (0x7fe617194000) libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000) libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000) libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000) libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe617194000) Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by bun) Error relocating bun: backtrace: symbol not found Error relocating bun: malloc_trim: symbol not found Error relocating bun: __cxa_thread_atexit_impl: symbol not found Error relocating bun: __sprintf_chk: symbol not found Error relocating bun: __strftime_l: symbol not found Error relocating bun: __register_atfork: symbol not found Error relocating bun: fcntl64: symbol not found Error relocating bun: __cxa_thread_atexit_impl: symbol not found Error relocating bun: __res_init: symbol not found
Installed using the YOLO method:
curl https://bun.sh/install | bash
.It seems the provided binaries are dynamically linked against a specific glibc version. The problem for @KaKi87 is likely that they have a different version of glibc. The problem in my case in that alpine uses musl instead of glibc.
Potential fixes for this:
* Check the glibc version on installation, and bail if there's a mismatch. * Provide statically linked binaries. If you use glibc for this, your entire project would need to be GPLv2, so you need to use musl for these builds.
Edit: I'd mixed up results from Debian and Alpine.
I would also like statically linked binaries with musl. I'm not having this specific issue but attempting to build bun from source myself causes a lot of errors on my computer unfortunately. I'd also like to be able to embed bun directly into the linux distro im building which requires statically linked binaries as well.
RHEL 8 ships glibc 2.28, bun requires 2.29
Big problem here.
I'm not able to run bun in MX Linux due to this issue. I have v2.28 of GLIBC and it seems I require v2.29. I'm hesitant to go down the rabbit hole of trying to upgrade GLIBC because I feel like last time I did that it tried to recompile every package I had and my system stopped working entirely. I'm on board with the static linking approach, in other words!
Spent all evening trying to figure out how the heck to build bun from source to try to understand/fix this problem or offer up a solution.
After a few frustrating hours all I had was a finished build of the custom version of zig required to build bun (which required installing an old version of LLVM).
Trying to make release-only
gave me an error about a missing cmakeconfig.h file. I'm sure there's about a thousand things I'm doing wrong with the build.
Wish there were some docs around how to build the project in the "right way" so I could help to debug this. I'm just too frustrated to work any more on this.
Really hope musl support get some attraction, all our server are alpine, BTW deno don't support musl too https://github.com/denoland/deno/issues/3711 , musl support can make adoption way easier not just for alpine but also all other disto with different glibc versions, without musl support, bun just ban a lot use-cases.
I'm also running libc 2.28 on my VPS and I'm physically unable to upgrade due to my provider's limitations... So, a version of bun that runs on 2.28 or lower would be nice.
I've been looking for workarounds. Tried compiling newer glibc, but my kernel is too old :(. Given what @aardvarkk said, I guess attempting to recompile bun itself would be a massive rabbit hole...
+1 for static binaries.
For anyone hitting this issue: don't try to upgrade glibc
, it's usually a recipe for breaking everything unless you really know what you're doing.
Trying to build bun
from source is much safer (worst case: you fail but your system is not entirely broken).
Due to being dynamically linked, it would need to be built with the exact same glibc you have.
Installing by building from source should work.
@WhyNotHugo If you can figure out and write up the process to build from source, please let me know! I tried for quite a while and it wasn't at all straightforward as far as I was concerned.
i try to install a newer version of glibc on a specified path /data/vendor/glibc-2.36; after using patchelf to modify interpret and rpath, i finally got it working with a little blemish:
see: https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host/44710599#44710599
Fixed in Bun v0.3.0
Please comment if you run into an issue like this again. We will need to watch for symbols from too-new versions of glibc going forward.
升级make版本到4.3 升级gcc版本到12.2 升级glibc版本到2.31 最好采用docker去做 不然很容易导致系统奔溃 挽回的余地都没有。。 慎重!!!!
Why do chinese people think that they can just speak chinese in any english conversation and be understood ?
It wouldn't come to my mind to suddenly pop here with a french message and expect to be understood.
PS: sorry for my initially incomplete message, I misclicked
`#!/bin/bash
#This entrypoint is to fix nokogiri archtecture problem in Apple Silicon
cd /var/www/myapp gem install nokogiri --platform=ruby bundle config set force_ruby_platform true bundle install
rails s -p 3000 -b '0.0.0.0' -e development `
I have added this entrypoint in my docker-compose. Worked for me!
@Jarred-Sumner
Fixed in Bun v0.3.0
This is still an issue in v0.6.3:
> ldd bun
/lib64/ld-linux-x86-64.so.2 (0x7f9a9e1c9000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f9a9e1c9000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9a9e1c9000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f9a9e1c9000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9a9e1c9000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by bun)
Error relocating bun: __memmove_chk: symbol not found
Error relocating bun: __fread_chk: symbol not found
Error relocating bun: __strcpy_chk: symbol not found
Error relocating bun: __memcpy_chk: symbol not found
Error relocating bun: __strcat_chk: symbol not found
Error relocating bun: __strncpy_chk: symbol not found
Error relocating bun: backtrace: symbol not found
Error relocating bun: __snprintf_chk: symbol not found
Error relocating bun: __sprintf_chk: symbol not found
Error relocating bun: gnu_dev_makedev: symbol not found
Error relocating bun: gnu_dev_major: symbol not found
Error relocating bun: gnu_dev_minor: symbol not found
Error relocating bun: __cxa_thread_atexit_impl: symbol not found
Error relocating bun: __printf_chk: symbol not found
Error relocating bun: __vsnprintf_chk: symbol not found
Error relocating bun: __fprintf_chk: symbol not found
Error relocating bun: __longjmp_chk: symbol not found
Error relocating bun: __vfprintf_chk: symbol not found
Error relocating bun: __strftime_l: symbol not found
Error relocating bun: __register_atfork: symbol not found
Error relocating bun: __cxa_thread_atexit_impl: symbol not found
Error relocating bun: unsupported relocation type 37
Error relocating bun: unsupported relocation type 37
Error relocating bun: unsupported relocation type 37
> ./bun
zsh: no such file or directory: ./bun
Note that the no such file or directory
error is misleading; it's the linker indicating that /lib64/ld-linux-x86-64.so.2
does not exist.
Please comment if you run into an issue like this again. We will need to watch for symbols from too-new versions of glibc going forward.
Huh? Are you sure you're not replying to the wrong issue?
Got this error too on CentOS 7.x Its very bad experience as it is because peoples will usually try the easiest method first to try stuff
got the same error.
environment
- Debian GNU/Linux
- CircleCI
I bought and downloaded the version from itch.io, running into the same error on Linux Mint 21.2, requiring GLIBC_2.36 but I have only 2.35 available