I've tried a python application on my CentOS machine and it gives me the following error:

ImportError: /usr/lib64/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/_MEI2BYIr4/libstdc++.so.6)

I've been tempted to upgrade GLIBC, but after having read some forums it seems I could break the system. Do you know any alternative?


  • it seems already dubious to have libstdc++ in /tmp/ . Was it done by the python application?
    – A.B
    Jan 29, 2018 at 17:52
  • 2
    There is no reason for any legitimate Python application to have placed a copy of a system C/C++ library under /tmp. Contact its developer and make sure you got a correct and clean copy of the program, and ensure that your system does not have malware now. Jan 29, 2018 at 22:23
  • @MichaelHampton Believe it or not, this looks like it's legit. The exact same path appears in a Github issue related to a bioinformatics tool: github.com/BioinformaticsFMRP/TCGAbiolinks/issues/…
    – user15323
    Jan 30, 2018 at 6:01
  • @duskwuff OK, that's a little bizarre. What on earth do they think they're doing? Jan 30, 2018 at 17:51
  • @MichaelHampton Scientists, man. As long as the research gets done…
    – user15323
    Jan 30, 2018 at 18:30

3 Answers 3


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.

  • 1
    This is really bad advice. glibc is not an ordinary library; installing it under a nonstandard path is likely to make the system unbootable.
    – user15323
    Jan 30, 2018 at 3:52
  • 1
    @duskwuff why, when it is only being called from an environment being set up to run this particular application? Jan 30, 2018 at 8:07
  • 1
    It doesn't if you build it with --prefix as I specified there. It's not a good solution but it works if it's unavoidable. I updated my answer with other options and that should really be a last resort. Jan 30, 2018 at 19:51
  • 2
    This is kind of the right answer, but it's also extremely dangerous. I don't think that's stressed enough here. We spent years in the late 1990s and early 2000s dealing with broken systems when people tried to upgrade glibc in place. If one isn't careful, one might accidentally replace system glibc with a different version and cause a broken system. Jan 30, 2018 at 20:30
  • 8
    Absolutely nothing wrong with installing libraries in a NON-standard path. The problem here is exporting LD_LIBRARY_PATH, which as @PacoelCuqui found, breaks everything, because then ALL programs run by any shell with the export use the new libc. The trick is to not export LD_LIBRARY_PATH but to place it on the command line ahead of the only the binaries which need it: $ LD_LIBRARY_PATH=/opt/glibc-2.18/lib my_special_program. A complication here is that it must be used before python prog.py which means Python also runs with the new libc - which could be a problem.
    – duanev
    Jan 16, 2019 at 19:51

In the end,I did not have to upgrade GLIBC. The gdc-client tool I downloaded through R seemed to be for Ubuntu and not CentOS, though I did it on CentOS 7. I then downloaded the gdc-client for CentOS and it worked fine.


On CentOS 7, I included the /usr/lib64 folder in the rpath as follows

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.18/lib:/usr/lib64 pydio-agent

This worked for me

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .