From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31901 invoked by alias); 15 Oct 2002 04:28:48 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 31893 invoked from network); 15 Oct 2002 04:28:47 -0000 Received: from unknown (HELO mta05ps.bigpond.com) (144.135.25.137) by sources.redhat.com with SMTP; 15 Oct 2002 04:28:47 -0000 Received: from bubble.local ([144.135.25.69]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15 mta05ps Jul 16 2002 22:47:55) with SMTP id H409RX00.11U for ; Tue, 15 Oct 2002 14:28:45 +1000 Received: from CPE-144-136-184-138.sa.bigpond.net.au ([144.136.184.138]) by PSMAM01.mailsvc.email.bigpond.com(MailRouter V3.0n 71/6703698); 15 Oct 2002 14:28:45 Received: (qmail 7362 invoked by uid 179); 15 Oct 2002 04:28:45 -0000 Date: Mon, 14 Oct 2002 21:28:00 -0000 From: Alan Modra To: Richard Henderson Cc: binutils@sources.redhat.com Subject: Re: elfNN-foo-fbsd hackery? Message-ID: <20021015135845.K22176@bubble.sa.bigpond.net.au> Mail-Followup-To: Richard Henderson , binutils@sources.redhat.com References: <20021015012721.GA24112@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021015012721.GA24112@redhat.com>; from rth@redhat.com on Mon, Oct 14, 2002 at 06:27:21PM -0700 X-SW-Source: 2002-10/txt/msg00348.txt.bz2 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