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>]

> Correct, AFAIK. But this is built with sparc as the default cpu target.

So you are *not* using a compiler configured for sparc64-linux
(contrary to the subject of your report). Please note that configuring
for sparc64-linux is different from configuring for sparc-linux, and
then using -m64. 

> Again, the compiler is setup to create sparc-linux binaries by
> default, I'm not sure why this autoconf test even has to pass
> -bsparc-linux

Also, having two compiler installations (one for sparc-linux, the
other for sparc64-linux) is different from multilibbing. 

For multilibs, you have a single installation which has multiple
copies of a library. In multiple installations, you have multiple
copies of the compiler, in different directories.

The more you report, the less I understand what exactly you are doing.

> I see the difference you were refering to: s/_vt.9bad_alloc/__vt_9bad_alloc/
> 
> Could you tell me where this symbol comes from, or what defines affect
> it's creation?

The symbol is the virtual function table of the bad_alloc class. The
compiler supports two different styles of virtual function tables. See
the documentation for -fvtable-thunks for details.

Mixing object files with different settings is guaranteed to fail; the
compiler enforces this by a different mangling for the virtual tables.
On some architectures (e.g. i586-pc-linux-gnu), vtable thunks are the
default, on most other architectures, the traditional style is the
default.

I don't know what the official ABI for sparc-linux is; this is defined
in /usr/include/_G_config.h. Once you know what the right mangling is,
you can investigate why part of the object files where
misconfigured/miscompiled. In turn, you either need to change the
compilation procedure for libstdc++, or you need to change the setting
of DEFAULT_VTABLE_THUNKS in the gcc/config/ .h file you are using.

Regards,
Martin