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

# rpm -qa | grep libc6

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:

# 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
  • 1
    Where did you get that libc6 package? Jan 24, 2013 at 21:17
  • Please provide the output of yum repolist.
    – ewwhite
    Jan 24, 2013 at 21:21
  • @ewwhite Okay, edited that in. Jan 24, 2013 at 21:31
  • @MichaelHampton, it was there when the server was turned over to me by the main IT department. I assume they got it from the RHEL repository, but I could check if it's relevant. Jan 24, 2013 at 21:31
  • You might find something useful about the package by inspecting it: rpm -qi libc6. It doesn't appear to be a Red Hat package. Jan 24, 2013 at 21:38

1 Answer 1


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...)

  • Thanks a lot, this was very helpful. I believe I know who is responsible for this state of affairs, and we will likely reinstall the server as a stock RHEL box. Much appreciated. Jan 24, 2013 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.