This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Version 0.0 of binutils is unsurprisingly feature-poor
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Phil Edwards <phil at jaj dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, gcc-regression at gcc dot gnu dot org, paul at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Mon, 20 Sep 2004 08:16:50 -0700
- Subject: Re: Version 0.0 of binutils is unsurprisingly feature-poor
- References: <20040919120457.2906.qmail@fenric.devphil.com><414E12BE.906@codesourcery.com> <20040920031601.GA29397@localhost><414E5393.7040004@codesourcery.com> <20040920042333.GA30437@localhost><414E60E6.60007@codesourcery.com> <20040920104028.GA1389@localhost>
Phil Edwards <phil@jaj.com> writes:
>
> Wheeeee, the gcc configury for binutils is so broken. I don't know how
> this is expected to work. This really looks like it's in the middle of
> changing, except the timestamp is days old.
I don't know a lot about this, but ...
> Yeah, version 0 doesn't support a whole lot of features. I wouldn't
> think version 0 would even support, ya know, *assembling*, but version==0
> doesn't signal an error. Also, some of the tests don't pass a version,
> so when the bogus $gcc_cv_as is run for that test, it fails.
Most (all?) of the tests are for optional features - if we haven't got
them, we may not be able to do spiffy things like .hidden, is all. So
failing a version check is quiet.
> (Since binutils is built first, there's an assembler binary already in
> place. The gcc configury knows this and symlinks to it. Why not run it to
> discover its version instead of grepping through Makefile.in and company?
> Presumably there's some kind of evil situation where the created symlink
> points to a nonexistant binary or something?)
When host != build, we can't run that assembler at all. Also, the
toplevel configure-gcc target may depend only on configure-gas, not
all-gas (I haven't gone and looked).
zw