Re: revert unintentional merge of config.gcc from mainline

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr 29, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Apr 29, 2002, "David S. Miller" <davem@redhat.com> wrote:
>> From: Mark Mitchell <mark@codesourcery.com>
>> Date: Sun, 28 Apr 2002 22:23:29 -0700

>> --On Sunday, April 28, 2002 09:04:06 PM -0700 "David S. Miller" 
>> <davem@redhat.com> wrote:
   
>>> Indeed I did.  Amazing in that based upon the way I do multi-tree
>>> commits I can't figure out how it happened.
   
>> Thanks for tracking this down.  If you haven't already, it's certainly
>> fine to undo the damage.

>> Therefore, Alexander, please install your fix.

> Done.  Unfortunately, FreeBSD 2.2 still isn't back to a fully
> functional state.  Even though it will bootstrap successfully, a
> number of tests in the testsuite fail to link due to the linker not
> resolving references to _GLOBAL_OFFSET_TABLE_.  I've been trying on
> and off to fix this, but so far I couldn't.  I have a working patch
> that removes the duplicate underscore from the front of the symbol,
> such that the assembler (presumably) recognizes it properly, but I
> still get link errors, and the linker reports double underscores in
> the symbol names, even though I see just a single one in the the
> source assembly.

And the reason why we get linker errors is apparently a linker bug.
The problem only shows up when linking with -lm, such that this finds
/usr/lib/libm.so.2.0.  Linking with /usr/lib/libm.a works.

Some further evidence to support the claim that it's a linker bug:

- Compiling and linking `int main() {}' with gcc 2.7.2.1 (that ships
with FreeBSD 2.2), it works.

- Compiling with this week's snapshot but linking with gcc 2.7.2.1, it
  works.

- Compiling and linking with this week's snapshot, it fails.  The only
  differences in the command line passed to /usr/bin/ld is the two
  occurrences of -lgcc (in snapshot) or /usr/lib/libgcc.a (in
  2.7.2.1).  There's no crtbegin/crtend that might make any
  difference.

- Ditto, but using /usr/lib/libgcc.a from gcc 2.7.2.1, instead of
  libgcc.a from this week's snapshot, it works.

- Linking all of the modules in the snapshot's libgcc.a that reference
  _GLOBAL_OFFSET_TABLE_ without libm.so.2.0 succeeds.

- Adding `int _GLOBAL_OFFSET_TABLE_;' to the test program and linking
  it with this week's snapshot works.

- There's no occurrence of _GLOBAL_OFFSET_TABLE_ in /usr/lib/libgcc.a.

I'm puzzled.  I don't see how to put all this evidence together
without concluding that /usr/lib/ld is in error, for failing to link
when /usr/lib/libm.so.2.0 is put in without /usr/lib/libgcc.a.

However, I know this used to work a couple of weeks (months?) ago,
with GCC 3.1 development snapshots.  Perhaps the GCC testsuite just
didn't link `-lm' in back then?

Any other ideas?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer