Glibc error in linux

‘GLIBC_2.25’ not found on Ubuntu (Windows Subsystem for Linux)

Now this answer is presumably going to come a bit late, but let me try to give you some technical background of what you ran into here and possible ways to fix it.

For starters, what was commented about is true. The glibc is the C runtime which is central to a Ubuntu system. However, other distros choose other runtimes and a program could also opt to statically link a runtime that is more liberally licensed (musl-libc comes to mind). The latter method has its limitations as well, though.

As a rule of thumb you can run the software that was built on your system. This is perfectly fine for a system such as certain BSDs or Gentoo Linux, but it starts to become an issue for pre-packaged distros like Debian and Ubuntu.

System calls

Your kernel provides a number of system calls. A certain subset of these is standardized some will be specific to your system, i.e. GNU/Linux in this case.

Most system calls — such as «open a file» — have a direct counterpart in your C runtime, but the C runtime often will provide additional stuff on top (e.g. facilities for dynamic linking . ).

C runtime

The glibc is a so-called shared object. Other systems call it dynamic library or dynamically linked library. The goal is largely the same, although implementation and functionality differ.

The term shared object refers to the fact that the object code («library functions») is shared across processes in your system.

Another advantage is that only this one library needs to be updated instead of each and every application that was statically linked with a particular version of the library.

And proprietary software (i.e. that which isn’t FLOSS) has the licensing issue because of certain «issues» the glibc license brings for someone unwilling to disclose their proprietary source code. Now this is evidently not the issue with your code, since you could go ahead and build your own.

Missing symbols

The error you encountered:

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

is one that I often jokingly confront people with who are complaining about «DLL hell» on Windows. Linux isn’t better and the conventional linkers give you little control of the symbols you link against.

Alright, let’s get our hands dirty a little. Make sure you have binutils installed ( apt install binutils ) and I’ll assume that you have the standard Bash shell installed and that it can be found in /bin/bash .

We’re going to start with the following invocation (instead of readelf , objdump would also work, but it has its own command line arguments):

readelf --dyn-syms /bin/bash|grep -P '\WUND\W' 

What it does is to list all dynamic symbols from the Bash binary and then limit the output to those items which are undefined ( UND ). This will give us the list of functions Bash uses from glibc. We can further refine this by removing all entries that refer to the GLIBC_2.2.5 version by appending grep -v ‘GLIBC_2\.2\.5’ :

$ readelf --dyn-syms /bin/bash|grep -P '\WUND\W'|grep -v 'GLIBC_2\.2\.5' 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __ctype_toupper_loc@GLIBC_2.3 (3) 3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND tgetflag@NCURSES_TINFO_5.0.19991023 (4) 6: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __snprintf_chk@GLIBC_2.3.4 (5) 14: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __vfprintf_chk@GLIBC_2.3.4 (5) 20: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab 22: 0000000000000000 0 FUNC GLOBAL DEFAULT UND tgetent@NCURSES_TINFO_5.0.19991023 (4) 25: 0000000000000000 0 FUNC GLOBAL DEFAULT UND tputs@NCURSES_TINFO_5.0.19991023 (4) 37: 0000000000000000 0 FUNC GLOBAL DEFAULT UND faccessat@GLIBC_2.4 (6) 50: 0000000000000000 0 FUNC GLOBAL DEFAULT UND tgoto@NCURSES_TINFO_5.0.19991023 (4) 60: 0000000000000000 0 FUNC GLOBAL DEFAULT UND eaccess@GLIBC_2.4 (6) 63: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __stack_chk_fail@GLIBC_2.4 (6) 72: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __fdelt_chk@GLIBC_2.15 (7) 80: 0000000000000000 0 FUNC GLOBAL DEFAULT UND tgetnum@NCURSES_TINFO_5.0.19991023 (4) 98: 0000000000000000 0 FUNC GLOBAL DEFAULT UND tgetstr@NCURSES_TINFO_5.0.19991023 (4) 101: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __asprintf_chk@GLIBC_2.8 (8) 104: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __memmove_chk@GLIBC_2.3.4 (5) 106: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __memcpy_chk@GLIBC_2.3.4 (5) 108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ 114: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.14 (9) 138: 0000000000000000 0 FUNC GLOBAL DEFAULT UND regexec@GLIBC_2.3.4 (5) 145: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __vsnprintf_chk@GLIBC_2.3.4 (5) 147: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __strncpy_chk@GLIBC_2.3.4 (5) 153: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __strcpy_chk@GLIBC_2.3.4 (5) 157: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __printf_chk@GLIBC_2.3.4 (5) 160: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __longjmp_chk@GLIBC_2.11 (11) 195: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __fprintf_chk@GLIBC_2.3.4 (5) 198: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable 215: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __ctype_tolower_loc@GLIBC_2.3 (3) 216: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __ctype_b_loc@GLIBC_2.3 (3) 219: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __sprintf_chk@GLIBC_2.3.4 (5) 

The 2.2.5 version was the first to support x86-64 as an architecture, which is why we’re not interested in it. The first available version will never pose an issue.

However, if you want this Bash binary on a system with «only» glibc 2.14 it would not work, because __fdelt_chk@GLIBC_2.15 requires at least version 2.15.

Interlude: symbol versioning

The @GLIBC_2.3.4 (etc.) suffix on the symbol names describe version ranges (also see here). This enables an ELF shared object to support multiple versions of a symbol. As an example a function foo() may have taken 2 arguments in version 1.0 of the library but 3 in the 2.x version range. The fact that software dynamically linking to these symbols contains the symbol version, means that it will always be linked to the appropriate version of a function.

However, the downside is what you encountered. Software linked on a system with a newer glibc (or really any other library also using symbol versioning) won’t run on your (older) system if one of the symbols used would require a newer library version than is available on your system.

The classical method to «overcome» this issue was always by building on a system that was old enough to provide a low enough common denominator as far as library versions were concerned. This even allowed you to some extent to run a binary built on one distro to run on a range of others. The downside is/was that this means older compiler, older toolchain, older libraries (because there are more libraries than just the C runtime).

Certain alternatives exist (see below), but they all require that you analyze exactly what it is you want. For example statically linking to musl-libc — which comes at more liberal licensing terms — won’t work if your program offers a plugin interface and exchanges buffers with the plugins . dynamically linking to the same C runtime is important in such a case. Besides, musl-libc and glibc can interfere with each other in the same process because of sbrk .

Possible solutions to your conundrum

• Run your software inside a VM on a more modern distro version which satisfies the library dependencies out of the box. Because the VM lets you run any kernel you desire, this will even work for software requiring very modern system calls.
• Run your software inside a chroot jail or a container (similar to the VM theme above, but here you could run into issues if the code running inside makes use of newer system calls not available on your host kernel, LXD 4.0 attempts to mitigate this issue by providing stubs for these system calls).
• Use an AppImage (someone needs to take care that the stub of the AppImage is as backwards compatible as possible, though.
• Use a snap package.

More involved solutions, or if you are a developer

• Offer a newer glibc version alongside the old one. Since this is a daemon there’s a chance something gets to start it. Whether it is systemd or good old SysV init, you should be able to set LD_LIBRARY_PATH to point it to your updated glibc.
• If you were the maintainer of said software, this approach would provide a viable alternative. What it does is to instruct the linker to choose an earlier version of the same symbol instead of the newest (picking the newest is the default).
  There is a project on GitHub under the name wheybags/glibc_version_header, which attempts to formalize this and may get you kickstarted.
  • This is a variation on the above approach.
  • This provides some more details on how to investigate the matter yourself.
  • This shows how to investigate the symbol version ranges required by a binary and the answer sheds some further light on the matter.
  • This is another explanation by the same user.

  If you’re actually interested in the internal workings of linkers you can grab a book on the subject matter or refer to Ian Lance Taylors excellent article series of which you can find an overview here.

  Источник

  Error while building glibc

  I’m trying to install glibc to debug a C-framework I’m working on. But, I’m getting an error in the build process. Here’s the error msg:

  make[3]: Leaving directory `/root/glibc-source/glibc-2.14/elf' /usr/bin/install -c /root/glibc-2.14-build/elf/ld.so /usr/local/myglibc/lib/ld-2.14.so.new mv -f /usr/local/myglibc/lib/ld-2.14.so.new /usr/local/myglibc/lib/ld-2.14.so /usr/bin/install -c /root/glibc-2.14-build/libc.so /usr/local/myglibc/lib/libc-2.14.so.new mv -f /usr/local/myglibc/lib/libc-2.14.so.new /usr/local/myglibc/lib/libc-2.14.so echo ld-2.14.so /usr/local/myglibc/lib/ld-linux-x86-64.so.2 >> /root/glibc-2.14-build/elf/symlink.list /usr/bin/install -c /root/glibc-2.14-build/elf/sotruss-lib.so /usr/local/myglibc/lib/audit/sotruss-lib.so.new mv -f /usr/local/myglibc/lib/audit/sotruss-lib.so.new /usr/local/myglibc/lib/audit/sotruss-lib.so make[2]: *** No rule to make target `/root/glibc-2.14-build/dlfcn/libdl.so.2', needed by `/root/glibc-2.14-build/elf/sprof'. Stop. make[2]: Leaving directory `/root/glibc-source/glibc-2.14/elf' make[1]: *** [elf/subdir_install] Error 2 make[1]: Leaving directory `/root/glibc-source/glibc-2.14' make: *** [install] Error 2 

  Is this a known problem? I had built glibc on the same machine earlier last week without any errors. I’m rebuilding it because glibc is compiled with optimization level 2(-O2) by default and I’m unable to look into the values of a few variables inside the library functions from the code dump as they’ve been optimized out. I’m currently trying to compile with optimization level 1. Thanks

  Источник

  Getting GLIBC_2.28 not found

  

  I running node -v command getting error:- node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28′ not found (required by node) Any solution

  13 Answers 13

  Finally I got solution by running by running following commands.

  sudo apt-get remove nodejs nvm install 16.15.1 

  node v16.15.1 version and npm v16.15.1 is installed. For same make sure nvm is installed in your machine.

  This is the only thing that worked after 2 days of scrounging for an answer. Had high hopes in this answer to solve it but it still didn’t: stackoverflow.com/questions/72513993/…

  you can install node v17.x by nvm(nodejs version manager).

  my OS version: Ubuntu 18.04.6 LTS

  I tried three ways to install node and npm in my pc:

  (fail) apt-get, the version is very old

  $ sudo apt-get install nodejs $ sudo apt-get install npm $ node -v v8.10.0 $ npm -v 6.1.0 

  $ curl -sL https://deb.nodesource.com/setup_14.x -o /tmp/nodesource14_setup.sh $ node -v v14.20.1 $ npm -v 6.1.0 

  $ sudo apt-get remove nodejs $ sudo apt-get remove npm $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.2/install.sh | bash $ chmod +x ~/.nvm/nvm.sh $ source ~/.bashrc $ nvm -v 0.39.2 $ nvm install 14 $ node -v v14.20.1 $ npm -v 6.14.17 $ nvm install 16 $ node -v v16.18.0 $ npm -v 8.19.2 $ nvm install 17 $ node -v v17.9.1 $ npm -v 8.11.0 # failed to install 18 $ nvm install 18 $ node -v node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node) $ npm -v node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node) 

  Источник