Multiple glibc libraries on a single host
It is very possible to have multiple versions of glibc on the same system (we do that every day).
However, you need to know that glibc consists of many pieces (200+ shared libraries) which all must match. One of the pieces is ld-linux.so.2, and it must match libc.so.6, or you'll see the errors you are seeing.
The absolute path to ld-linux.so.2 is hard-coded into the executable at link time, and can not be easily changed after the link is done (Update: can be done with patchelf; see this answer below).
To build an executable that will work with the new glibc, do this:
g++ main.o -o myapp ... \
-Wl,--rpath=/path/to/newglibc \
-Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2
The -rpath
linker option will make the runtime loader search for libraries in /path/to/newglibc
(so you wouldn't have to set LD_LIBRARY_PATH
before running it), and the -dynamic-linker
option will "bake" path to correct ld-linux.so.2
into the application.
If you can't relink the myapp
application (e.g. because it is a third-party binary), not all is lost, but it gets trickier. One solution is to set a proper chroot
environment for it. Another possibility is to use rtldi and a binary editor. Update: or you can use patchelf.
How to install multiple versions of glibc?
If you just want the dynamic libraries from the other version of glibc you can simply use LD_LIBRARY_PATH. But if you want to fully use the other version you need to compile against the other version to get the static parts. And you might want to compile the other version of glibc as well to get all the hardcoded paths to point to your installation directory for loading datafiles and plugins (for NSS and gconv). Using --prefix=/usr/glibc2.3.4
will also set the soname of the dynamic loader to /usr/glibc2.3.4/lib/ld-linux.so.2
(or something similar depending on your architecture) which will be hardcoded into every program linked against it.
Removing glibc dependency when compiling with gcc
Is it possible to compile a program using gcc without depending on glibc?
Yes, there are alternative libc
versions, such as Musl, uClibc, dietLibc, etc. See their documentation on how to use them.
Your problem does not appear to be a GLIBC dependency, but rather a mismatch between your build and your target hosts. In particular, your target has older GLIBC than your build host.
The easiest to solution for that problem is to build on an old-enough system -- your binary will run on anything that is as-old or newer. You could do that inside a VM or in a docker container, so you don't have to downgrade your main system.
You could also link your program statically (add -static
flag), but beware -- for many non-trivial programs this will make your binary less portable.
Related Topics
Looping Through the Content of a File in Bash
How to Set the Environmental Variable Ld_Library_Path in Linux
Can Windows Containers Be Hosted on Linux
Forward Host Port to Docker Container
How to Upgrade Glibc from Version 2.12 to 2.14 on Centos
How Can a Process Intercept Stdout and Stderr of Another Process on Linux
Filter Log File Entries Based on Date Range
Difference Between Clock_Realtime and Clock_Monotonic
How to Run Script as Another User Without Password
Bash Script Processing Limited Number of Commands in Parallel
Why Does /Bin/Sh Behave Differently to /Bin/Bash Even If One Points to the Other