* Version 0.0 of binutils is unsurprisingly feature-poor (was Re: Regression for csl-arm on arm-none-elf)
[not found] ` <414E60E6.60007@codesourcery.com>
@ 2004-09-20 13:45 ` Phil Edwards
2004-09-20 16:11 ` Version 0.0 of binutils is unsurprisingly feature-poor Zack Weinberg
0 siblings, 1 reply; 4+ messages in thread
From: Phil Edwards @ 2004-09-20 13:45 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc-regression, paul, gcc
Finally had some time this morning to look into these failures. I'm a
little tired and slap-happy right now, so this mail is a bit weird.
On Sun, Sep 19, 2004 at 09:47:34PM -0700, Mark Mitchell wrote:
> From looking at the logs, I see that the compiler really doesn't think
> it understands the visibility attribute. That means that when you
> configured the compiler, HAVE_GAS_HIDDEN did not get defined.
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.
> Did you configure with --with-gnu-as --with-as=/path/to/arm-none-elf-as
> and similarly for GNU ld?
Yes, sortof. Toplevel detects when building a unified gcc+src tree,
and adds the --with-gnu-* arguments when recursing to the gcc subdir.
When the gcc configury tries to figure out what binutils are in use, it
knows to check for an assembler over in the sibling build dir. But it
gets two things wrong for unified trees:
1) It doesn't set $gcc_cv_as to the new assembler. This variable gets
set on all the other as-discovery paths, and then used later for
feature testing. So this needlessly goes through some huge loop
and then gets some bogus string.
2) It tries to set the assembler version by grepping through 4 files,
none of which have the string it wants. There is no error; gcc
configury then assumes the version is "0". How this lived through
testing I don't know; I suspect the breakage is recent and nobody
has tried this scenario yet.
Now, normally the lack of $gcc_cv_as isn't a problem, because each of the
feature test macros is /supposed/ to be called with a minimum version as well
as some test code. If it's a unified tree, the version is checked, else
the test code is assembled.
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.
Same for the linker and other binutils.
(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?)
> What do your configure logs say about hidden
> support?
They don't say a #!@%$ thing, because the gcc/aclocal.m4 binutils tests
don't write failed test source and command lines to config.log, like a
normal autoconf test does. Grumble.
--
<Patrician|Away> what does your robot do, sam?
<bovril> it collects data about the surrounding environment, then discards
it and drives into walls
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Version 0.0 of binutils is unsurprisingly feature-poor
2004-09-20 13:45 ` Version 0.0 of binutils is unsurprisingly feature-poor (was Re: Regression for csl-arm on arm-none-elf) Phil Edwards
@ 2004-09-20 16:11 ` Zack Weinberg
2004-09-20 16:52 ` Paolo Bonzini
0 siblings, 1 reply; 4+ messages in thread
From: Zack Weinberg @ 2004-09-20 16:11 UTC (permalink / raw)
To: Phil Edwards; +Cc: Mark Mitchell, gcc-regression, paul, gcc
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Version 0.0 of binutils is unsurprisingly feature-poor
2004-09-20 16:11 ` Version 0.0 of binutils is unsurprisingly feature-poor Zack Weinberg
@ 2004-09-20 16:52 ` Paolo Bonzini
2004-09-20 17:41 ` Paolo Bonzini
0 siblings, 1 reply; 4+ messages in thread
From: Paolo Bonzini @ 2004-09-20 16:52 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Mark Mitchell, gcc-regression, paul, gcc
> 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).
It can depend on all-gas. It did not when host configures were ran at
configure time. Still, it diminishes the amount of parallelism in the
build process.
Paolo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Version 0.0 of binutils is unsurprisingly feature-poor
2004-09-20 16:52 ` Paolo Bonzini
@ 2004-09-20 17:41 ` Paolo Bonzini
0 siblings, 0 replies; 4+ messages in thread
From: Paolo Bonzini @ 2004-09-20 17:41 UTC (permalink / raw)
To: gcc; +Cc: gcc-regression
> 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).
It can depend on all-gas. It did not when host configures were ran at
configure time. Still, it diminishes the amount of parallelism in the
build process.
Paolo
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-09-20 15:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20040919120457.2906.qmail@fenric.devphil.com>
[not found] ` <414E12BE.906@codesourcery.com>
[not found] ` <20040920031601.GA29397@localhost>
[not found] ` <414E5393.7040004@codesourcery.com>
[not found] ` <20040920042333.GA30437@localhost>
[not found] ` <414E60E6.60007@codesourcery.com>
2004-09-20 13:45 ` Version 0.0 of binutils is unsurprisingly feature-poor (was Re: Regression for csl-arm on arm-none-elf) Phil Edwards
2004-09-20 16:11 ` Version 0.0 of binutils is unsurprisingly feature-poor Zack Weinberg
2004-09-20 16:52 ` Paolo Bonzini
2004-09-20 17:41 ` Paolo Bonzini
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).