Hi,
On Tue, 19 Feb 2013, Stephan Bergmann wrote:
> I'm puzzled by the following on Linux, where I don't understand what causes it
> that a given symbol is exported as "u" (when viewed with nm, which documents
> "u" as "a unique global symbol. This is a GNU extension...") or not:
>
> * On an older toolchain (SLED 11 with GCC 4.3.4 and binutils 2.21.1), we have
>
> > $ nm -D /usr/lib64/libstdc++.so.6.0.16 | grep empty_rep_storage
> > 00000000002f7660 u
> > _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
> > 00000000002f7580 B _ZNSs4_Rep20_S_empty_rep_storageE
This shared lib actually comes from the gcc46 toolchain, which does
support unique symbols (4.3 does not). That one symbol is unique and the
other isn't seems to be a bug in our link editor. The object files still
contain unique definitions:
% nm .libs/*.o | grep empty_rep_storage
U _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
0000000000000000 u _ZNSs4_Rep20_S_empty_rep_storageE
U _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
U _ZNSs4_Rep20_S_empty_rep_storageE
0000000000000000 u _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
But then, when linking those together one remains unique, and the other is
transformed into a normal object. The difference between both symbols is
that for one (_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE)
the definition comes last in the input .o files (in wstring-inst.o)
without following references (they all come before the def), while
for the other (_ZNSs4_Rep20_S_empty_rep_storageE) the definition (in
string-inst.o) is followed by another reference (from wlocale-inst.o).
I.e. it looks like as if a following reference once the link editor saw
the definition of the symbol resets it's unique status. I can make both
symbols wrong/non-unique by placing wlocale-inst.o last in the linker
cmdline.
Bad :-/
Ciao,
Michael.
