This came up over at http://gcc.gnu.org/ml/gcc/2013-02/msg00227.html
describing a strange mismatch between two symbols that are unique, but
in the shared object one is normal and the other is unique.  I traced
this back to an ordering problem in ld at http://gcc.gnu.org/ml/gcc/2013-02/msg00239.html .  The binutils involved
there are 2.21.1, but current upstream still exhibits the issue.  I made a
minimal testcase with two asm files:

% cat unique1.s
        .file   "unique.cc"
        .weak   _ZN1SIiE1iE
        .section        .bss._ZN1SIiE1iE,"awG",@nobits,_ZN1SIiE1iE,comdat
        .align 4
        .type   _ZN1SIiE1iE, @gnu_unique_object
        .size   _ZN1SIiE1iE, 4
_ZN1SIiE1iE:
        .zero   4
        .ident  "GCC: (GNU) 4.6.1 20110505 (prerelease)"
        .section        .note.GNU-stack,"",@progbits

% cat unique2.s
        .file   "unique.cc"
        .text
        .align 2
        .globl  _ZN1SIiE3getEv
        .type   _ZN1SIiE3getEv, @function
_ZN1SIiE3getEv:
.LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        movq    %rdi, -8(%rbp)
        movq    _ZN1SIiE1iE@GOTPCREL(%rip), %rax
        movl    (%rax), %eax
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE0:
        .size   _ZN1SIiE3getEv, .-_ZN1SIiE3getEv
        .ident  "GCC: (GNU) 4.6.1 20110505 (prerelease)"
        .section        .note.GNU-stack,"",@progbits

% gcc -c unique1.s unique2.s
% ./ld/ld-new -shared -o unique-ok.so unique2.o unique1.o
% ./ld/ld-new -shared -o unique-bad.so unique1.o unique2.o
% nm -D unique-bad.so | grep _ZN1SIiE1iE
0000000000200398 B _ZN1SIiE1iE
% nm -D unique-ok.so | grep _ZN1SIiE1iE
0000000000200398 u _ZN1SIiE1iE

In difference is that for unique-ok.so the reference to _ZN1SIiE1iE comes
first (in unique2.o), then the definition (in unique1.o), and that results
correctly in a global unique symbol exported from the DSO.
For unique-bad.so the definition comes first, and the uniqueness seems to
get lost when the normal reference is seen, so a normal global (not even weak)
symbol is now exported from the DSO.

This can (and as the thread at gcc@ shows actually does) lead to problems
when the system relies on some symbols to be indeed globally unique.
The empty_rep static member of libstdc++'s string<> and wstring<> templates
is one example.

As said, this is broken in at least 2.21.1 and in current trunk.  FWIW,
the C++ source I used to initially generate the above asms is:

template <typename T>
struct S {
    static T i;
    T get();
};
template <typename T> T S<T>::i;
template <> int S<int>::get() { return i; }

compiled with -fPIC, and then split the .s into two by hand.