Description of problem: While trying to debug an unrelated anaconda issue I ran into the problem that I cannot build anaconda with glibc-2.5-23 (which is new today it appears). A bunch of _nl_* symbols are now multiply defined or chagned: /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o):(.rodata+0xa0): multiple definition of `_nl_category_name_sizes' ../stubs/libunicode-lite.a(unicode-lite.o):(.rodata+0x0): first defined here /usr/bin/ld: Warning: size of symbol `_nl_category_name_sizes' changed from 104 in ../stubs/libunicode-lite.a(unicode-lite.o) to 13 in /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o) /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o):(.rodata+0x90): multiple definition of `_nl_category_name_idxs' ../stubs/libunicode-lite.a(unicode-lite.o):/usr/src/redhat/BUILD/anaconda-11.1.2.112/stubs/unicode-lite.c:45: first defined here /usr/bin/ld: Warning: size of symbol `_nl_category_name_idxs' changed from 1 in ../stubs/libunicode-lite.a(unicode-lite.o) to 13 in /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o) /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o):(.rodata+0x0): multiple definition of `_nl_category_names' ../stubs/libunicode-lite.a(unicode-lite.o):(.data.rel.ro.local+0x0): first defined here /usr/bin/ld: Warning: size of symbol `_nl_category_names' changed from 104 in ../stubs/libunicode-lite.a(unicode-lite.o) to 137 in /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o) /usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../libc.a(setlocale.o): In function `_nl_locale_subfreeres': (__libc_freeres_fn+0x280): multiple definition of `_nl_locale_subfreeres' I confirmed if I go back to glibc-2.5-21 the problem goes away. Also a quick diff of glibc soruces does indeed show changes in this area. Version-Release number of selected component (if applicable): I will upload the full log file of the build also. How reproducible: 100% Steps to Reproduce: 1. yum update (to get latest glibc) 2. rpmbild -bb anaconda.spec 3. Actual results: Expected results: Additional info:
Created attachment 302064 [details] output of rpmbuild -bb anaconda.spec
Then anaconda should be changed accordingly. Does it use libc.a gettext but not libc.a locale stuff? That's risky to say at least. I guess anaconda will have the same problem in rawhide then... All that changed in this area is that now __libc_setlocale_lock is a rwlock rather than mutex.
-Wl,-M should help figure out why these .o files are now brought in and weren't before.
--- anaconda-11.1.2.112/stubs/unicode-lite.c.jj 2008-04-08 18:17:36.000000000 -0400 +++ anaconda-11.1.2.112/stubs/unicode-lite.c 2008-04-11 03:40:02.000000000 -0400 @@ -116,5 +116,8 @@ const size_t _nl_category_name_sizes[] = /* avoid bringing in glibc's setlocale.o - we want to use our fake setlocale() */ -typedef pthread_mutex_t __libc_lock_t; -__libc_lock_t __libc_setlocale_lock; +union +{ + pthread_mutex_t mtx; + pthread_rwlock_t rwlck; +} __libc_setlocale_lock __attribute__((nocommon)); should fix this (at least loader links). As the stub doesn't use __libc_setlocale_lock and so it is there only to satisfy wcsmbsload.o, the above should make it work both with older and newer glibc (i.e. no matter if it is actually a mutex, libc one int mutex or rwlock). All the default mutex, libc one int mutex and rwlock initializers are all zeros, and nocommon means the symbol will be preferred over the one in libc.a (setlocale.o) where it is STT_COMMON.
A quick scratch build earlier did not reproduce this issue, though I suppose that's simply because the latest glibc has not made it into the right tree yet. We have at least one more reason to do a rebuild of anaconda, so I'll ACK this.
This will be fixed in anaconda-11.1.2.113-1.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0397.html