Re: problems compiling gcc 2.95.[12] for sparc64-linux using --with-cpu=sparc

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> I'm not saying it is a problem in the PIC, nor a problem in sparc64. It is
> a problem in how the sparc32 compiler is generated when compiling for
> sparc64-linux (note that it is multilib, and default is sparc32, and
> should compile the code the same as a sparc-linux compiler, but it doesn't).

Thanks for the information. There is a number of things that confuse
me in your report; perhaps you can help resolving them.

1. I thought sparc64 is not officially supported in GCC, is that not
   true?

2. You say you are using a sparc64-linux installation (which indeed
   would multilib for m32/m64), yet in the commands you invoke, I only
   see the "sparc-linux" architecture, on which there is no
   multilibbing.

> Note this output (after a `ar x libgcc.a'):

You can use use 'nm -o' on libgcc.a; this saves you the
un-ar-ring. The symbol should be defined in new.o.

> 0000000000000000  w    O .gnu.linkonce.d._vt.9bad_alloc 0000000000000020
> _vt.9bad_alloc

This this the definition of the symbol. I'm surprised that it is not
_vt_9bad_alloc; I thought gcc uses vtable thunks on Linux on all
architectures.

> Also, here is the same config.log with LDFLAGS=-Wl,-v

I actually meant 'c++ -v'. In addition, you could try
-Wl,--verbose. That should tell you whether the linker is picking up
new.o.

> /usr/lib/gcc-lib/sparc-linux/2.95.2/libstdc++.so: undefined reference to `bad_alloc virtual table'

Please do 'nm' on that library, as well - perhaps the symbol has a
different spelling.

Regards,
Martin