Re: disturbing g++ 971031 results. defer-pop not to blame.

[Robert Lipe <robertl@dgii.com>]

Found it.

[ disassembly showing crap in .fini deleted ] 

> If I take hte final link line:
> 
>  /play/negcs/gcc/ld -b elf -Ra,XPG4PLUS,ELF -YP,/usr/ccs/lib:/lib:/usr/lib \
>         -Qn /usr/ccs/lib/crt1.o /usr/ccs/lib/values-Xa.o \
>         /play/negcs/gcc/crtbegin.o -L/play/negcs/gcc -L/usr/ccs/bin \
>         -L/usr/ccs/lib -L/usr/local/lib net34.o -lstdc++ \
>         -lgcc -lcrypt -lgen -lc -lgcc /play/negcs/gcc/crtend.o \
>         /usr/ccs/lib/crtn.o
> 
> and play with the order (add crtn.o before or after -lstdc++) I have 
> reason to think that it's from something in libstdc++.   If I just
> hoist -lstdc++ down to the very last (and stick another -lgcc after
> it) I get a functioning executable.
> 
> Objdump --all-headers on libstdc++.a and all the .o's that go into
> it shows nothing in the .fini section.
> 
> How can I find out what this is and where it's coming from?

Ugh.  I'm going to be ill.

The stupid final link line listed above includes a '-L/usr/local/lib'
but does not include a -L/play/negcs/libraries.    This means that 
while I spent hours staring at a disassembly of 
/play/negcs/libraries/libstdc++/libstdc++.a that looked perfectly 
reasonable, the linker was using one from /usr/local/lib from 
June 2 that happens to contain crap in the .fini section.

Of course, the obvious way to fix this is to add -L/play/libraries
to the link line - but then '-mcoff' picks up the wrong libraries.

Part of me wonders why this is dependent upon the level of 
optimization and the stack layout of the net34.o object when 
the problem is "clearly" in a linked-in library, and part of 
me just wants to rewire my tests to manually include the 
appropriate libes for ELF and COFF and get on with my life.

RJL