glibc_2.18 on Centos 7

Issues related to applications and software problems
Post Reply
mujina
Posts: 1
Joined: 2019/07/25 12:39:50

glibc_2.18 on Centos 7

Post by mujina » 2019/09/24 11:18:44

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.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: glibc_2.18 on Centos 7

Post by TrevorH » 2019/09/25 20:36:02

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.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

User avatar
jlehtone
Posts: 4523
Joined: 2007/12/11 08:17:33
Location: Finland

Re: glibc_2.18 on Centos 7

Post by jlehtone » 2019/09/26 07:21:45

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/

Post Reply