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