This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: elfNN-foo-fbsd hackery?
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Richard Henderson <rth at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Tue, 15 Oct 2002 13:58:45 +0930
- Subject: Re: elfNN-foo-fbsd hackery?
- References: <20021015012721.GA24112@redhat.com>
On Mon, Oct 14, 2002 at 06:27:21PM -0700, Richard Henderson wrote:
> * Makefile.am (BFD64_BACKENDS): Remove elf64-alpha-fbsd.lo
> (BFD64_BACKENDS_CFILES): Remove elf64-alpha-fbsd.c
> * elf64-alpha-fbsd.c: Remove file. Move code ...
> * elf64-alpha.c: ... here.
Exactly what I intended doing when I found a spare moment. x86 has
qnx to contend with as well.
Of course, the bloat only happens when you enable multiple bfd
targets, and I have a nagging suspicion that certain operations
(*) might bomb with "File format is ambiguous" if you provide
two bfd vectors.
*) Like "objcopy -O binary blah.o blah.bin". Hmm, here's an
example:
$ .../all/binutils/objcopy -O binary powerpc-linux/libiberty/hex.o blah.bin
all/binutils/objcopy: powerpc-linux/libiberty/hex.o: File format not recognized
$ .../x86/binutils/objcopy -O binary powerpc-linux/libiberty/hex.o blah.bin
$
The "all" objcopy is --target=i686-linux --enable-targets=all,
while the "x86" objcopy is --target=i686-linux
--enable-targets=i686-linuxaout,i686-coff,hppa-linux,powerpc-linux
The first case fails because we're reading a non-default object which
matches multiple powerpc targets, while the second case works because
we only have one matching target. Not that I think this is
particularly worrying. I'm just illustrating the point that providing
two targets may not be desirable in all situations.
Gack, and that's a terrible error message from objcopy. Fixing..
--
Alan Modra
IBM OzLabs - Linux Technology Centre