10

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?

Thanks

Improve this question
6
  • it seems already dubious to have libstdc++ in /tmp/ . Was it done by the python application? – A.B Jan 29 '18 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. – Michael Hampton Jan 29 '18 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/… – duskwuff -inactive- Jan 30 '18 at 6:01
  • @duskwuff OK, that's a little bizarre. What on earth do they think they're doing? – Michael Hampton Jan 30 '18 at 17:51
  • @MichaelHampton Scientists, man. As long as the research gets done… – duskwuff -inactive- Jan 30 '18 at 18:30
15

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 five 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
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib

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

Improve this answer
10
  • 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. – duskwuff -inactive- Jan 30 '18 at 3:52
  • @duskwuff why, when it is only being called from an environment being set up to run this particular application? – Simon Greenwood Jan 30 '18 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. – Simon Greenwood Jan 30 '18 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. – Michael Hampton Jan 30 '18 at 20:30
  • 5
    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 '19 at 19:51
3

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.

Improve this answer
2

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.