![]() 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 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Īnd 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 Note this must only be done for the application only. You can build the version of glibc you require elsewhere on your server and add it to LD_LIBRARY_PATH for the application. This can potentially affect the functionality of your computer so make sure you know what you are doing.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: ![]() As a last resort, install glibc in a nonstandard location 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. 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.Īn up to date glibc on CentOS 7 should be 2.17-196.el7_4.2 If it is needed, Containerise ![]() Firstly check the python application as it could be out of date and is probably misreading the glibc version. ![]()
0 Comments
Leave a Reply. |