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 (-:

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/11583] ld aborts in elf_link_output_extsym when given EXTERN() symbol in script.

[nickc at redhat dot com]

--- Additional Comments From nickc at redhat dot com  2010-05-11 14:16 
---
Created an attachment (id=4778)
 -- (http://sourceware.org/bugzilla/attachment.cgi?id=4778action=view)
Cope with unresolved references when exporing symbols


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11583

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils