GLIBC version problem

Latest response

I want to install a Control M Fix Pack 500, but when I put the comand /tmp/ControlM/PAKAI. to install the fix pack but the system get the error

/bin/ksh: /lib64/ version `GLIBC_2.23' not found (required by /bin/ksh)

I understand the problem, I need to update the GLIBC package, but when I want to update I have other problem, the latest version of the package is the 2.17

[root@srrmdilm2usb202 ~]# yum info glibc-devel.x86_64
Loaded plugins: enabled_repos_upload, package_upload, product-id, search-disabled-repos, subscription-manager
Installed Packages
Name : glibc-devel
Arch : x86_64
Version : 2.17
Release : 196.el7
Size : 1.0 M
Repo : installed
From repo : rhel-7-server-rpms
Summary : Object files for development using standard C libraries.
License : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+
Description : The glibc-devel package contains the object files necessary
: for developing programs which use the standard C libraries (which are
: used by nearly all programs). If you are developing programs which
: will use the standard C libraries, your system needs to have these
: standard object files available in order to create the
: executables.
: Install glibc-devel if you are going to develop programs which will
: use the standard C libraries.

and I dont have idea to update this package, do you have any solution for that?


My OS is Red Hat Enterprise Linux Server release 7.4 (Maipo)


/bin/ksh: /lib64/ version `GLIBC_2.23' not found (required by /bin/ksh)

This describes a two-tier library dependency:

  • /bin/ksh requires, which has been successfully located for loading at /lib64/
  • /lib64/ requires a version of glibc (i.e. with a tag GLIBC_2.23

The problem with this is that in RHEL 7.x, the libc RPM package is glibc-2.17-.el7.x86_64.rpm, and it includes both /lib64/ and /lib64/ Have you replaced your /lib64/ with a version from some other non-RHEL source?

Please run this command: rpm -Vv glibc | grep -v '^.........' If it outputs nothing, then all the files that come from the glibc RPM are all unchanged on your system. Any output lines will indicate files that have been modified in some way: the first 9 characters on the line will indicate what kind of change has been detected. If the changed files are configuration files, that is OK; but if a non-configuration file belonging to the glibc RPM has been changed outside the control of the RPM package manager, that's an error. To fix it, you can run yum reinstall glibc - but you might want to find out why the replacement was done first!

Also do the same for ksh: rpm -Vv ksh | grep -v '^.........'

If these commands indicate no changes, run ldd /bin/ksh to get the exact path names of all the libraries used by the ksh shell. If one of those comes from a non-RHEL source, it might be a problem in library loading order: check file /etc/ and directory /etc/, and environment variables LD_PRELOAD and LD_LIBRARY_PATH.

You can also run objdump -p /lib64/ and look under the "Version definitions" and "Version References" headings in its output: the "Version definitions" lists the version tags the library provides for other applications and libraries, and "Version References" indicate the version tags it needs from other libraries in order to successfully run. These might give you clues for determining the original source of the possible rogue /lib64/ on your system.

Rhel 7 not have support for glibc-2.23 The actual support is for glibc-2.17 We need wait for rhel8, but if you need run your app, maybe can probe install without support. This is the procedure: (I assume in this example that gcc and development libraries are already installed) I was execute this procedure for glibc-2.18. It is the same for the version that you need. Have a pot of coffee because compiling takes a lot time!!!! relax!!!

/--------------/ download glibc-2.18.tar.gz

unpakage: tar -xzvf glibc-2.18.tar.gz

cd glibc-2.18

mkdir eag

mkdir /opt/glibc-2.18

cd eag

../configure --prefix=/opt/glibc-2.18


---> If you are sure you compiled correctly and are subject to your OS being out of support, then install !!!

make install

export LD_LIBRARY_PATH=/opt/glibc-2.18/lib:$LD_LIBRARY_PATH

Probe your apps!!!

Hi Everyone,

Be careful and know the risk of using a non-Red-Hat version of glibc. glibc is at the heart of the libraries of Red Hat and using a non-Red-Hat version can cause definite issues, which would be rather impossible at the moment to fully describe without a deep dive in comparing standard Red Hat glibc and whoever provided a non-Red-Hat glibc.

I generally regard glibc updated for example to be a higher impact than installing a new kernel.

Now what Edwin says above may indeed work, yet just be aware it will ruin support for that system you install a non-Red-Hat glibc on. Please DO have a total-complete backup of your system, namely of the data you care about that the server is hosting, and any configurations you established through intense diligent research that could be lost if the system is lost. Be prepared with an action plan to rebuild the server and represent the services and data as required (with the backups you have made just in case the experimental non-Red-Hat glibc goes "bad").

Kind Regards,

RJ Hinton Thank you very much for supplementing the risk of installing a non-RHEL version of glibc. GLIBC, as you say, is the heart of the OS libraries and it will always cause serious problems in the use of the system if a version that is not defined by RHEL is used.

getting error as GLIBC_2.14 not found in RHEL 6.4. is this version is compatible for RHEL 6.4. please guide

This is a fairly old thread, but what RJ says is correct.

The GNU C library is the basis upon which all other userspace is versioned, so definitely don't go installing glibc package from somewhere else. You'll almost certainly break the system and need to recover or reinstall.

This error happens because the software expects a glibc version number later than what that RHEL release ships with. The software vendor hasn't made their software compatible with that RHEL release.

The broadest way to get around this would be to run the software in a container. That will let you run later userspace, such as the current RHEL major release which does have a later glibc, without changing anything else on the base system.

It is theoretically possible to uncompress later libraries into a non-system directory, then use that directory as the LD_LIBRARY_PATH to run the software. This is simple for something which just needs one library like glibc, but gets messy quickly when you need to interact with other libraries on the system as you're crossing versions which may not be compatible.

You could also ask the software vendor support. They may have a way to work around the version requirement. Presumably if they're shipping enterprise software then they would have knowledge of how to run their software on an enterprise distro like RHEL.

Thanks for the additional clarification Jamie,

Anyone using RHEL 6, please see this discussion which describes RHEL 6 as being outside Maintenance Support II. If you do not have Extended Update support, you are vulnerable.


Hii guys is it possible to install glibc2.29 on rehl-7 without unstable the whole system if it is possible please revert back

No, it isn't. However, there are multiple alternative options discussed in the posts above, so you can look into the best one of those which meets your needs.