------- Comment #11 from jakub at gcc dot gnu dot org 2010-01-28 22:49 -------
LD_DEBUG=all ./main 2>&1 | grep _ZSt4cerr
12758: symbol=_ZSt4cerr; lookup in file=./main [0]
12758: binding file /usr/lib64/libstdc++.so.6 [0] to ./main [0]:
normal symbol `_ZSt4cerr' [GLIBCXX_3.4]
12758: symbol=_ZSt4cerr; lookup in file=/lib64/libdl.so.2 [0]
12758: symbol=_ZSt4cerr; lookup in file=/usr/lib64/libstdc++.so.6 [0]
12758: binding file ./main [0] to /usr/lib64/libstdc++.so.6 [0]:
normal symbol `_ZSt4cerr' [GLIBCXX_3.4]
12758: symbol=_ZSt4cerr; lookup in file=./library.so [0]
12758: symbol=_ZSt4cerr; lookup in file=/usr/lib64/libstdc++.so.6 [0]
12758: binding file ./library.so [0] to /usr/lib64/libstdc++.so.6 [0]:
normal symbol `_ZSt4cerr' [GLIBCXX_3.4]
The first lookup is for std::cerr relocations in libstdc++, the second one is
just to find out what should be the std::cerr COPY relocation in main be
initialized for. Thus, the executable uses std::cerr inside of main's .bss.
But during RTLD_DEEPBIND first library.so and its dependencies are searched, so
the copy in libstdc++.so.6 (which hasn't been initialized at runtime) is used.
Note that std::cerr isn't STB_GNU_UNIQUE, so this crashes even on Fedora 12.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
