Home / server / Questions / 472196
Accepted
Will Martin
Asked: 2013-01-25 13:07:52 +0800 CST

glibc.i686 conflicts with libc6?

  • 772

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?

EDIT:

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
redhat

1 Answers

  1. Best Answer

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

    • 1