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 packages :-( Version-Release number of selected component (if applicable): glibc-2.2.4-19.3 How reproducible: Didn't try Additional info: 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? Pre-existing: gcc-2.96-85 Upgrades: kernel-2.4.16-0.13.i686 glibc-2.2.4-19.3.i386 modutils-2.4.12-3 less-358-23 [+ others] Severity increased because of the lack of pre-warning (other than using rawhide!)
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 testing.
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 packages? 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.