Ask questionsRelease linux musl builds

When trying to run deno on Centos 7, it fails:

[maxim@maxim deno] $ target/release/deno tests/worker.js
target/release/deno: /lib64/ version `GLIBC_2.18' not found (required by target/release/deno)

Additional information: First things first, Centos 7 is based on RHEL 7, as one may know. And, according to

In Red Hat Enterprise Linux 7, the glibc libraries (libc, libm, libpthread, NSS plug-ins, and others) are based on the glibc 2.17 release

Replacing system glibc is a very bad idea, basically because all binaries on the system are compatible with specific glibc version. So, that's not an option.

However, the RHEL 8 Beta is using glibc 2.28 (source), but Centos 8 will only be released when the stable version of RHEL 8 will be released (source), so updating Centos is not an option right now.

I have also tried installing glibc in a nonstandard location as described here. Unfortunately, when I try to run deno with that custom glibc, I'm getting:

[maxim@maxim deno]$ LD_LIBRARY_PATH=/opt/glibc-2.18/lib target/release/deno tests/worker.js
Segmentation fault (core dumped)

I've tried to debug it with lldb, gdb, abrt, but neither option worked for me. Probably, because I'm doing something wrong. lldb:

[maxim@maxim deno]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib lldb -- target/debug/deno tests/worker.js
lldb: relocation error: /opt/glibc-2.18/lib/ symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file with link time reference


[maxim@maxim deno]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib gdb target/release/deno tests/worker.js
gdb: relocation error: /opt/glibc-2.18/lib/ symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file with link time reference

And abrt won't detect any crashes, even though I've set OpenGPGCheck = no and ProcessUnpackaged = yes in /etc/abrt/abrt-action-save-package-data.conf, restarted abrtd and abrt-ccpp, and finally tried rebooting, nothing helped. I hope, that I'm doing something wrong, because right now I think using custom glibc is the only option, if I don't want to containerize deno.

Also, as far as I understand, GLIBC_2.18 isn't a direct requirement of deno, but rather a requirement of some third-party. I've found Chromium bug glibc dependency creeped up to 2.18 in M61, breaking EL7 support which seems relevant, but it was fixed a while ago. I'm not really good in C or library symbols to find which dependency requires 2.18, so any help here would be really appreciated.

I hope that @ry also would agree that we should support Centos, and probably when this issue got fixed, we can run travis not only for Ubuntu 14.04 LTS (trusty) but also for Centos. Many thanks for your attention!


Answer questions kt3k

Amazon Linux 1 (not 2) also seems having this problem. I tried the above 2 binaries, but these don't seem working

(in amazon linux 1)
[ec2-user@ip-172-31-255-61 test]$ wget
[ec2-user@ip-172-31-255-61 test]$ gunzip deno_x64_linux.gz
[ec2-user@ip-172-31-255-61 test]$ chmod +x deno_x64_linux 
[ec2-user@ip-172-31-255-61 test]$ ./deno_x64_linux 
./deno_x64_linux: /lib64/ version `GLIBC_2.18' not found (required by ./deno_x64_linux)

(note: AWS Lambda uses Amazon Linux 1 as its runtime environment. So this also seems blocking running deno in AWS Lambda).

I found a similar issue in rust repository and it seems suggesting building binary in old distro to solve this problem.

Yoshiya Hinosawa kt3k @denoland Tokyo, Japan A web dev in 🇯🇵. Contributing to @denoland. Maintaining @c3js and @capsidjs.,
Github User Rank List