The title says it all. Is there a way of getting glibc_2.18 on Centos 7?
What are pros/cons and howtos for the workaround?
(For example, building glibc_2.18 from source, as adviced here https://github.com/istio/istio/issues/9358,
or use containers, as adviced here https://serverfault.com/questions/89462 ... n-centos-7,
or run a vm in centos 7 and do everything there).
As I understand, solution 1 would risk breaking the OS if you installed glibc anew. But would it be possible and safe and easy to just build glibc_2.18 and keep in a non-standard location, without installing it, and then pointing your applications to that location (with environment variables, include/libs flags, etc)?
For option 2 I wouldn't know what to try exactly, as I have no experience with containers.
For option 3, it's kind of a pain to have all your work in a vm, but maybe it's the safest and conceptually easier of the bunch.
Other options?
Thank you.
glibc_2.18 on Centos 7
Re: glibc_2.18 on Centos 7
No. Never going to happen. We ship glibc 2.17 as part of CentOS 7 and that will never change. It's part of the basic RHEL standards that stuff like this does not change within a major version.
CentOS 8 died a premature death at the end of 2021 - migrate to Rocky/Alma/OEL/Springdale ASAP.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are dead, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are dead, do not use them.
Use the FAQ Luke
Re: glibc_2.18 on Centos 7
Note though that (RHEL/CentOS) package version Y can differ greatly from the upstream version Y that existed years ago and was the base for (RHEL/CentOS) package. The policy of backporting fixes.
You probably ask, because you have a binary that has been linked against glibc-2.18. No amount of backporting will solve that.
The traditional method is to recompile and link against the glibc that you have. Sadly, that is not always feasible.
Containers are the current hype. Therefore, try them. EPEL has package 'singularity'. https://sylabs.io/guides/3.4/user-guide/
You probably ask, because you have a binary that has been linked against glibc-2.18. No amount of backporting will solve that.
The traditional method is to recompile and link against the glibc that you have. Sadly, that is not always feasible.
Containers are the current hype. Therefore, try them. EPEL has package 'singularity'. https://sylabs.io/guides/3.4/user-guide/