Description of problem: After updating to gcc-4.4.1-2 (and friends), programs fail to start. For example: [tbl@tlondon fixed]$ rhythmbox Gtk-Message: Failed to load module "gnomebreakpad": /usr/lib64/libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4 (rhythmbox:20373): Rhythmbox-WARNING **: /usr/lib64/libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4 (rhythmbox:20373): Rhythmbox-WARNING **: Could not load plugin audiocd (rhythmbox:20373): Rhythmbox-WARNING **: Error, impossible to activate plugin 'Audio CD Player' [tbl@tlondon fixed]$ Downgrading to 4.4.1-1 "makes it work" again. Version-Release number of selected component (if applicable): libgcc-4.4.1-2.x86_64 libstdc++-4.4.1-2.x86_64 libgomp-4.4.1-2.x86_64 libgfortran-4.4.1-2.x86_64 cpp-4.4.1-2.x86_64 gcc-4.4.1-2.x86_64 gcc-gfortran-4.4.1-2.x86_64 libstdc++-devel-4.4.1-2.x86_64 gcc-c++-4.4.1-2.x86_64 How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Do you have glibc-2.10.90-7 or later installed? Wasn't that app started before upgrade to that glibc?
No, I have glibc-2.10.90-3.x86_64 installed. I tried installing newer glibc, but got pthread errors in some apps. I started that app after I completed the "yum update gcc"...
Everything built during or after yesterday needs the new glibc. If you get pthread errors with glibc-2.10.90-7.1, please report them instead. But you really can't use older glibc than that with the new packages.
Good to know. Thanks!
(In reply to comment #3) > Everything built during or after yesterday needs the new glibc. > If you get pthread errors with glibc-2.10.90-7.1, please report them instead. > But you really can't use older glibc than that with the new packages. I was about to file a bug before I found this report. I don't quite agree with this diagnosis - while I don't have glibc-2.10.90-7.1 yet, I downloaded 4.4.1-1 and did an nm -D on both versions: --------------------------------- 792,793c792,793 < V _ZNSbIwSt11char_traitsIwESaIwEE4_Rep11_S_max_sizeE < V _ZNSbIwSt11char_traitsIwESaIwEE4_Rep11_S_terminalE --- > u _ZNSbIwSt11char_traitsIwESaIwEE4_Rep11_S_max_sizeE > u _ZNSbIwSt11char_traitsIwESaIwEE4_Rep11_S_terminalE 797c797 < V _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE --- > B _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 803c803 < V _ZNSbIwSt11char_traitsIwESaIwEE4nposE --- > u _ZNSbIwSt11char_traitsIwESaIwEE4nposE 1020,1021c1020,1021 < V _ZNSs4_Rep11_S_max_sizeE < V _ZNSs4_Rep11_S_terminalE --- > u _ZNSs4_Rep11_S_max_sizeE > u _ZNSs4_Rep11_S_terminalE ... ... ------------------------------------ 38 weak (V) symbols became undefined (u) and 2 became (B) data sections. Maybe somebody can explain to me how pthread changes in glibc results in 40 weak symbols disappearing?
Undefined symbols are U, not u. u is for STB_GNU_UNIQUE symbols, a GNU extension introduced into the toolchain now.
(In reply to comment #6) > Undefined symbols are U, not u. u is for STB_GNU_UNIQUE symbols, a GNU > extension introduced into the toolchain now. Ok... the manpage of nm needs updating :-). Thanks for the explanation - did notice the STB_GNU_UNIQUE change, didn't quite know what impact it has. Presumably you aren't talking about glibc itself but the link-loader needs updating to support the new symbol type?