nm x86 bug when configured for linux and solaris

[Duncan Simpson]

I configured binutils with
$../binutils/src/configure -C --prefix=/usr --enable-shared --enable-gold 
--with-sysroot=/ --enable-lto 
--enable-targets=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu,i686-sun-solaris2

and the built version nm says
$./nm-new --help says
<usage and options snipped>
supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux pei-i386 pei-x86-64 
elf64-l1om elf64-little elf64-big elf32-little elf32-big elf32-i386-sol2 
coff-i386 elf64-x86-64-sol2 srec symbolsrec verilog tekhex binary ihex
$./nm-new /solaris/bin/ls
./.libs/lt-nm-new: /solaris/bin/ls: File format is ambiguous
./.libs/lt-nm-new: Matching formats: elf32-i386 elf32-i386-sol2

This is suboptimal behaviour IMHO particular because the output of nm
is the same for both formats.

The same problem affects 32 bit linux binaries two and the problem is not
limited to nm, objdump, objcopy, ranlib and ld are also affected. The
impact of the latter is reduced because gcc, g++, etc specify an emulation
and therefore avoid the problem.

Duncan (-: