Current Deno release 1.0.0 (latest today) is not compatible with CentOS 7.

I tried on the latest distribution released on 27 April 2020:

$ cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)

This issue 7 GLIBC_2.18 not found suggests that there should be a way to solve this problem, but the thread seems to be abandoned for a year.

As of today Deno requires GLIBC_2.18, but unfortunately CentOS 7 is running 2.17, an old version of the gclib which is not enough:

$ ldd --version
ldd (GNU libc) 2.17

If you need to run Deno on CentOS you'll need to use CentOS 8. Tested it and it works.

From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”:

That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).

It will not happen for CentOS 7. From glibc_2.18 on Centos 7:

No. Never going to happen. We ship glibc 2.17 as part of CentOS 7 and that will never change. It's part of the basic RHEL standards that stuff like this does not change within a major version.

I wouldn't count on Deno — which is a new technology — to backport with old compilers. Consider upgrading your servers to CentOS 8.

You can upgrade to the Red Hat Enterprise Linux 8, which comes with glibc 2.28 and thus provides the GLIBC_2.18 symbol version (and much more).

If you do not want to upgrade, you need a Redis build for Red Hat Enterprise Linux 7. Red Hat provides a Software Collection with Redis 3.2 (available in the scl channels). There is also a CentOS build of Redis 3.2, again as a software collection. If that version is too old, you will have to build Redis from source. EPEL only contains Redis 3.2 as well.

Upgrading glibc within a current release in Red Hat Enterprise Linux (or CentOS) is not possible.

webrtc-checkout/src/buildtools/linux64/gn: /lib64/libc.so.6: version 'GLIBC_2.18' not found

This error means that gn has been built on a GLIBC-2.18 (or later) system, and requires GLIBC-2.18 to run.

Any pointers on how I can resolve this without upgrading the glibc version

You can build gn from source on your system.

Alternatively, you may be able to install glibc-2.18 or above as a second glibc, without upgrading the "main" glibc. This answer provides details.

Check it is actually needed

Firstly check the python application as it could be out of date and is probably misreading the glibc version. CentOS shows the base version as installed and is patched to keep up with changes and it could just be a case of fixing the version that is being looked for in the code as a quick fix, but if the application is being actively developed you need to let the developers know or fork it for yourself if you can.

An up to date glibc on CentOS 7 should be 2.17-196.el7_4.2

If it is needed, Containerise

If it's absolutely necessary to run this application, the official RHEL approach would be to containerize, but you would still need to provide a working glibc, which wouldn't be possible with stock CentOS 7.

As a last resort, install glibc in a nonstandard location

If this isn't viable, and as an absolute last resort, it is possible to install a newer version of glibc than 2.18 as that is 9 years old now and glibc has been updated for several vulnerabilities and I'm not sure off the top of my head if it will build with the version of make in CentOS 7, but any newer version should work as follows:

• This can potentially affect the functionality of your computer so make sure you know what you are doing

You can build the version of glibc you require elsewhere on your server and add it to LD_LIBRARY_PATH for the application. Note this must only be done for the application only.

wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz
tar zxvf glibc-2.18.tar.gz
cd glibc-2.18
mkdir build
cd build
../configure --prefix=/opt/glibc-2.18
make -j4
sudo make install

Then to run a binary you need to use patchelf to update its interpreter

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 program_you_are_running

And you need to enable it to find the new glibc library, either by

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib

Or you can use patchelf to update the binary's rpath (you can combine this with the previous pathelf command)

patchelf --set-rpath /opt/glibc-2.18/lib:/usr/lib64 program_you_are_running

If you change LD_LIBRARY_PATH don't export it for the whole system because all the binaries unmodified by patchelf will segfault.

/opt is the standard place to install third-party applications and libraries but you can use any path away from the system paths.

So why am I getting GLIBC_2.14 error?

Because your program depends on a symbol with that version, and you are running it on a system which doesn't provide it.

Shouldn't it be 2.19 error?

No.

When a new symbol is introduced, it gets a version assigned to it. Usually that version is the not yet released glibc version, i.e. if the current released version is 2.13, the new symbol gets version 2.14 assigned to it.

That version stays with this symbol (unless a new and incompatible version of the same symbol is introduced later).

The x86_64 GLIBC-2.19 has the following versioned symbols:

$ objdump -T /lib/x86_64-linux-gnu/libc.so.6 | grep ' g ' | head
0000000000078110 g    DF .text  0000000000000124  GLIBC_2.2.5 putwchar
0000000000096a70 g    DF .text  0000000000000020  GLIBC_2.2.5 __strspn_c1
000000000010a2b0 g    DF .text  0000000000000010  GLIBC_2.4   __gethostname_chk
0000000000096a90 g    DF .text  000000000000001a  GLIBC_2.2.5 __strspn_c2
0000000000110570 g    DF .text  00000000000000a5  GLIBC_2.2.5 setrpcent
00000000000a7ba0 g    DF .text  000000000000000a  GLIBC_2.2.5 __wcstod_l
0000000000096ab0 g    DF .text  0000000000000022  GLIBC_2.2.5 __strspn_c3
00000000000fa950 g    DF .text  0000000000000021  GLIBC_2.3.2 epoll_create
000000000010a2c0 g    DF .text  0000000000000010  GLIBC_2.4   __getdomainname_chk
00000000000fab60 g    DF .text  0000000000000021  GLIBC_2.2.5 klogctl
....

That is, if I link a program that calls putwchar, I will need at minimum version 2.2.5, but if my program also calls epoll_create, then I will need a minimum version of 2.3.2.

Your program calls some symbol with version GLIBC_2.14, most likely this one:

0000000000091620 g   iD  .text  000000000000003d  GLIBC_2.14  memcpy

Your program is known to not call any of the symbols below (or you would have gotten a different required version):

$ objdump -T /lib/x86_64-linux-gnu/libc.so.6 | egrep 'GLIBC_2.1[5-9]'
000000000010ab30 g    DF .text  0000000000000014  GLIBC_2.16  __ppoll_chk
00000000001087d0  w   DF .text  000000000000003e  GLIBC_2.17  clock_getcpuclockid
000000000010aaf0 g    DF .text  0000000000000017  GLIBC_2.15  __fdelt_warn
000000000010aaf0 g    DF .text  0000000000000017  GLIBC_2.15  __fdelt_chk
000000000003c6b0 g    DF .text  00000000000000fc  GLIBC_2.18  __cxa_thread_atexit_impl
00000000000fb070 g    DF .text  0000000000000024  GLIBC_2.15  process_vm_writev
00000000000bd420 g    DF .text  00000000000001ba  GLIBC_2.15  scandirat
00000000000af970 g    DF .text  0000000000000019  GLIBC_2.16  c16rtomb
00000000001088f0  w   DF .text  0000000000000090  GLIBC_2.17  clock_nanosleep
00000000000af6e0 g    DF .text  0000000000000282  GLIBC_2.16  mbrtoc16
00000000000a3c70  w   DF .text  0000000000000230  GLIBC_2.16  mbrtoc32
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.15  GLIBC_2.15
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.16  GLIBC_2.16
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.17  GLIBC_2.17
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.18  GLIBC_2.18
00000000000b9f40 g    DF .text  0000000000000042  GLIBC_2.16  timespec_get
0000000000083120  w   DF .text  0000000000000009  GLIBC_2.16  aligned_alloc
0000000000108810  w   DF .text  0000000000000025  GLIBC_2.17  clock_getres
0000000000108880  w   DF .text  0000000000000064  GLIBC_2.17  clock_settime
00000000000f8240  w   DF .text  0000000000000068  GLIBC_2.16  getauxval
00000000000e44f0 g    DF .text  0000000000000015  GLIBC_2.15  posix_spawn
0000000000108840  w   DF .text  000000000000003b  GLIBC_2.17  clock_gettime
00000000000a3ea0  w   DF .text  00000000000001ea  GLIBC_2.16  c32rtomb
000000000003c0b0  w   DF .text  000000000000001b  GLIBC_2.17  secure_getenv
000000000010ab10 g    DF .text  0000000000000014  GLIBC_2.16  __poll_chk
00000000000f8240 g    DF .text  0000000000000068  GLIBC_2.16  __getauxval
00000000000fb040 g    DF .text  0000000000000024  GLIBC_2.15  process_vm_readv
00000000000bd420  w   DF .text  00000000000001ba  GLIBC_2.15  scandirat64
00000000000e4510 g    DF .text  0000000000000015  GLIBC_2.15  posix_spawnp

I've got this error with buildroot-2022.11 when executing make.

Ubuntu 20.04 - added this repo as described in the link

sudo apt update
sudo apt install libc6

It automatically installed 2.35 for me.