Will Martin asked:
I have a 64-bit Redhat Enterprise Linux server (version 6.3) that doesn’t want to let me install the glibc.i686 module for 32-bit compatibility. When I try
yum install glibc.i686 as root, it gives me a long string of errors like this:
Transaction Check Error: file /lib/libc.so.6 from install of glibc-2.12-1.80.el6_3.6.i686 conflicts with file from package libc6-6:2.15-1.x86_64 file /lib/libm.so.6 from install of glibc-2.12-1.80.el6_3.6.i686 conflicts with file from package libc6-6:2.15-1.x86_64 file /lib/libpthread.so.0 from install of glibc-2.12-1.80.el6_3.6.i686 conflicts with file from package libc6-6:2.15-1.x86_64
Here’s the output of
rpm -qa grepping for glibc and libc6:
# rpm -qa | grep glibc glibc-common-2.12-1.80.el6_3.6.x86_64 glibc-2.12-1.80.el6_3.6.x86_64 # rpm -qa | grep libc6 libc6-2.15-1.x86_64
Google has not produced anything terribly helpful despite my best efforts.
Why do these two packages conflict, and how do I make them play nicely together?
Here is the output of
# yum repolist Loaded plugins: product-id, rhnplugin, subscription-manager Updating certificate-based repositories. Unable to read consumer identity repo id repo name status rhel-x86_64-server-6 Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) 8,824 repolist: 8,824
There is no
libc6 package in Red Hat Enterprise Linux. The package name for the same files is
glibc. It appears that someone installed a package on your server from a different Linux distribution, and overrode the errors they would have received upon attempting to do so (which are just about the same as those you saw here).
This of course puts your RPM database in an inconsistent state relative to the actual software installed, and may cause compatibility and dependency problems such as that you ran into today. It becomes no longer possible to update packages from the supported repositories, for instance, and difficult to determine exactly what code is running on the system.
My best guess is that someone (who really doesn’t know the right way to do this) attempted to upgrade glibc beyond the version provided by Red Hat, most likely to take advantage of a new feature which isn’t present in the version of glibc shipped with EL6.
The right way, if you really need this late version of glibc, is to take Red Hat’s source RPM, tweak the spec file and any patches to build the new version of glibc, and use the new binary RPMs of the new version. You then are responsible for maintaining it yourself, may lose vendor support, etc. so this is something you should only think about if business requirements absolutely demand it. (And since you lose your support anyway, you may as well switch to CentOS…)
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.