This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: disturbing g++ 971031 results. defer-pop not to blame.
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