libstdc++ clashes with libC system library on Irix 6.5

[Wolfram Gloger]

Hello,

I'm not arguing this is a bug in gcc, but I've hit the following
problem on Irix-6.5 (it does _not_ happen on Irix-6.2):

max:/home/wmglo/src/test% gcc -v
Reading specs from /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/specs
gcc version 2.95.2 19991024 (release)
max:/home/wmglo/src/test% gcc hello.cc -lstdc++
max:/home/wmglo/src/test% ./a.out 
Hello, world.
max:/home/wmglo/src/test% gcc hello.cc -lstdc++ -lC  
ld32: WARNING 85: definition of __rethrow in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 85: definition of __throw in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 85: definition of __dynamic_cast in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 85: definition of cin in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 85: definition of cout in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 85: definition of cerr in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 85: definition of clog in /pkg/gcc-2.95.2/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libstdc++.so preempts that definition in /usr/lib32/libC.so.
ld32: WARNING 84: /usr/lib32/libC.so is not used for resolving any symbol.
[so far so good, no function from libC will ever be used directly..]
max:/home/wmglo/src/test% ./a.out 
Segmentation fault (core dumped)

This has been reported before:

 http://gcc.gnu.org/ml/gcc/1999-04/msg00246.html

It _is_ sometimes necessary to pull in SGI's libC C++ library into
gcc-compiled applications, for example those using OpenGL, because of
the unfortunate fact that libGLU pulls libC in unconditionally.
(Recompiling libGLU with gcc is not an option.. :-)

Now I suppose the problem must be that libC in its global constructors
does something bad to objects in libstdc++.  Could those objects be
`tucked away' by rebuilding gcc with flag_honor_std turned on by
default?  (Squangling wouldn't help here, I think..)

IOW, could this possibly be a workaround for the clash?

Thanks,
Wolfram.