Version 0.0 of binutils is unsurprisingly feature-poor (was Re: Regression for csl-arm on arm-none-elf)

Version 0.0 of binutils is unsurprisingly feature-poor (was Re: Regression for csl-arm on arm-none-elf)

[Phil Edwards]

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

Re: Version 0.0 of binutils is unsurprisingly feature-poor

[Zack Weinberg]

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

Re: Version 0.0 of binutils is unsurprisingly feature-poor

[Paolo Bonzini]

> 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

Re: Version 0.0 of binutils is unsurprisingly feature-poor

[Paolo Bonzini]

> 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