From: Ian Lance Taylor <ian@airs.com>
To: James E Wilson <wilson@specifixinc.com>
Cc: Alan Modra <amodra@bigpond.net.au>,
Nick Clifton <nickc@redhat.com>, Ben Elliston <bje@au1.ibm.com>,
binutils@sources.redhat.com
Subject: Re: build failure for ia64 (due to -Werror)
Date: Fri, 18 Mar 2005 22:49:00 -0000 [thread overview]
Message-ID: <m3is3ou0az.fsf@gossamer.airs.com> (raw)
In-Reply-To: <1111177693.9897.18.camel@aretha.corp.specifixinc.com>
James E Wilson <wilson@specifixinc.com> writes:
> On Fri, 2005-03-18 at 04:21, Alan Modra wrote:
> > I would guess 32-bit host, no --enable-64-bit-bfd. Then "bfd_vma insn"
> > is 32-bit and ia64_insn is long long. There's worse things in that code
> > than type-punned pointers..
>
> I believe this can only happen if --enable-targets=all is used.
>
> I see this is a documented feature in configure.in. This seems like a
> flaw to me. The elfxx-ia64.c file won't work without a 64-bit integer
> type, and it seems unreasonable to try to fix this. A quick look seems
> to suggest that other elf64-* files have the same problem. elf64-ppc.c
> is using bfd_get_64 for instance, as are some others.
>
> I suppose I could add something like
> #ifndef BFD64
> #error This target requires a 64 bit integer type.
> #endif
> to the elfxx-ia64.c file to make the problem more obvious if people
> think something needs to be done.
>
> It might be better to fix the --enable-targets=all support. We have
> enough 64-bit targets by now that perhaps --enable-targets=all should
> force use of BFD64.
If you don't have a 64-bit host, nor a 64-bit target, nor do you
configure with --enable-64-bit-bfd, then --enable-targets=all should
only permit the use of 32-bit targets. This is implemented through
the rather odd mechanism of using #ifdef BFD64 in bfd/config.bfd, from
which targmatch.h is constructed.
Perhaps this has broken somehow.
Ian
next prev parent reply other threads:[~2005-03-18 21:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-18 3:58 Ben Elliston
2005-03-18 13:14 ` Nick Clifton
2005-03-18 14:13 ` Alan Modra
2005-03-18 22:15 ` James E Wilson
2005-03-18 22:49 ` Ian Lance Taylor [this message]
2005-03-18 23:31 ` Ian Lance Taylor
2005-03-18 23:52 ` James E Wilson
2005-03-18 23:37 ` Andreas Schwab
2005-03-19 0:42 ` Alan Modra
2005-03-19 1:56 ` Andreas Schwab
2005-03-19 4:04 ` James E Wilson
2005-03-19 4:30 ` Andreas Schwab
2005-03-19 9:44 ` James E Wilson
2005-03-19 12:13 ` James E Wilson
2005-03-19 17:57 ` James E Wilson
2005-03-19 18:37 ` Alan Modra
2005-03-19 18:33 ` James E Wilson
2005-03-19 19:00 ` Andreas Schwab
2005-03-23 9:45 ` James E Wilson
2005-03-23 19:24 ` Nick Clifton
2005-03-24 9:27 ` James E Wilson
2005-03-24 14:58 ` Nick Clifton
2005-03-19 0:56 ` Alan Modra
2005-03-22 2:19 ` Ben Elliston
2005-03-20 9:26 Paul Schlie
2005-03-20 19:42 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3is3ou0az.fsf@gossamer.airs.com \
--to=ian@airs.com \
--cc=amodra@bigpond.net.au \
--cc=binutils@sources.redhat.com \
--cc=bje@au1.ibm.com \
--cc=nickc@redhat.com \
--cc=wilson@specifixinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).