When linking a relocatable object, where any input object has the defined global
versioned symbols, gold cuts the symbol version for the symbols in the output
symbol table. It means, that kind of symbols lose the version information in the
output object; also, if the input object has two versions of one symbol --
versioned and non-versioned -- the output object will contain two symbols with
identical names (duplicate).

There is some example for GNU gold (GNU Binutils 2.20.51.20100304) 1.9

This is a part of readelf output for the input object (readelf -sW divdi3.os),
which shows the versioned and non-versioned symbols for __divdi3:

Symbol table '.symtab' contains 34 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
    20: 000005dc   120 FUNC    GLOBAL DEFAULT    1 __divdi3
...
    30: 000005dc   120 FUNC    GLOBAL DEFAULT    1 __divdi3@GLIBC_2.4
...

Link the input object as relocatable with the following command:

ld -r -o divdi3.out divdi3.os


This is a part of readelf output for the result object (readelf -sW divdi3.out),
which shows the symbol duplicates for __divdi3:

Symbol table '.symtab' contains 27 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
    13: 000005dc   120 FUNC    GLOBAL DEFAULT    1 __divdi3
...
    24: 000005dc   120 FUNC    GLOBAL DEFAULT    1 __divdi3
...

(I will attach the complete readelf outputs to the bug report)

So, as far as I understood, it happens because of two linked problems: the
Symbol_table::sized_write_symbol method always looks for the non-versioned
version of symbol in the symbol names string pool; and the symbol names string
pool never gets a string representation for that kind of versioned symbols (i.e.
the strings like "name@ver").