Red Hat Bugzilla – Bug 57652
libc.so.6: version `GCC_3.0' not found (required by XYZ)
Last modified: 2016-11-24 09:53:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Description of problem:
Number of upgraded programs fail - on a dependency that is not detected at
installation time? (These include xinetd-2.3.4-0.3, modutils-2.4.12-3,
less-358-23... from rawhide). Common factor appears to be the above
comment from libc.so.6, hence report for glibc. (glibc-2.2.4-19.3 just
upgraded). Downgrading the other packages seems to restore functionality,
but this is not the easiest thing to do without the functionality in those
Version-Release number of selected component (if applicable):
Haven't tried to reproduce - not managed to get system back into fully
working condition yet.
Why any requirement on having a compiler present at all (GCC_3.0)? Or does
this mean something else?
Severity increased because of the lack of pre-warning (other than using
Using rawhide means sufficient warning.
To use packages from rawhide which have been built with gcc 3.1 you need
glibc-2.2.4-20 or later (and be prepared for problems too).
This actual problem is going away with the new eh registry scheme which has
been commited in the last days in gcc and binutils, but it still needs further
OK, understand about version of glibc - found 2.2.4-20 on rawhide now I've
looked more closely :-)
But - why aren't these packages throwing up unresolved dependency warnings on
installation - unless this relates to the "eh registry" scheme you refer to?
I think I'm more concerned that there is a major requirement change in packages
compiled with GCC 3.1 that is not reflected in the dependencies in those
If that's in hand, then all well and good, but if not - well, it's fairly
predictable I would guess.
Thanks for the very prompt and well targeted response. I'm impressed.
rpm until recently limited the versioning checks to GLIBC_ symbols.
New registry functions in glibc have to use GCC_3.0 symbols to be binary
compatible with gcc 3.0 and up.
This is fixed in current rpm version I think and as I said, since new eh
registry scheme uses no registration routines at all, this particular problem
will go away no matter what.