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 (-: _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
