The bug is triggered by the --as-needed switch.

The problem is in bfd/elflink.c in the function elf_link_add_object_symbols().
When an input file is linked with the ---as-needed in effect, the  
elf_link_add_object_symbols() function
(1) clones the symbol table;
(2) adds the new information
(3) restores the symbol table if it turns out that the new input is  
*not* needed.

The problem is that on bullet (2) things are modified that aren't  
restored on bullet (3).
The main problem is that elf_link_add_object_symbols() calls the
*bed->elf_backend_copy_indirect_symbol()
function both directly and in a nested way on some calls of  
_bfd_elf_merge_symbol().
elf_backend_copy_indirect_symbol is elfNN_ia64_hash_copy_indirect() on  
ia64 (in /bfd/elfnn-ia64.c).
elfNN_ia64_hash_copy_indirect() moves the info about the usage of  
dynamic symbols from one symbol to another; it is an array of struct  
elfNN_ia64_link_hash_entry in separately allocated memory.
It sets the ->info member of the symbol to NULL and adjusts the ->h  
member of all dynamic symbols to the target symbol.
When elf_link_add_object_symbols() restores the symbol table (3), the  
->info member (which was NULL) is set to the former array of dynamic  
symbols, but the ->h members of the dynmaic symbols point to another  
symbol.
The other symbol is deleted (freed memory); when the implementation  
walks through the symbols in a later stage, the crash occurs. (The  
failed assert is just a side effect.)

There is another thing which is modified on (2) but isn't restored on (3):
The bfd_elf_link_record_dynamic_symbol() function is called, which may  
add a new string to the string table via _bfd_elf_strtab_add().
Since the string table isn't restored by elf_link_add_object_symbols  
(3), the result is a failing assert on writing out the string table on  
a later stage:
bfd/elf-strtab.c:273:
      BFD_ASSERT (tab->array[i]->refcount == 0);


ref:
http://bugs.debian.org/718047