g++ compatibility with libC on Solaris

[Andrew Pimlott <andrew at pimlott dot ne dot mediaone dot net>]

I'm using egcs 1.1.1 on SunOS 5.5.1.  I have no trouble compiling and
running C++ programs.

My problem is that I wish to compile my C++ code with g++, but link it with
a (third-party, binary only) dynamic library that was compiled with the Sun
C++ compiler.  In our tests, this appears to introduce major
incompatibilites, and I would like to know if there are strategies for
working around them.

I believe the incompatibility lies in the coexistance of the Sun C++ runtime
(libC.so, to which my third-party library is dynamically linked), and the
g++ C++ runtime (libstdc++, whether linked dynamically or statically).  The
eventual outcome is a bus error, which gdb shows occuring in either libC or
libstdc++ code.  If the same code is compiled with Sun's C++ compiler (so
that only libC is involved), the errors go away.  It seems clear that symbol
clashes are involved, but possibly there are other culprits as well.

I know the short answer to this is "don't do that", but due to several
constraints, I must try.  The following approaches seem plausible to me:

- modify the stdc++ library and g++ so that symbols do not overlap those of
  libC.

- link in such a way that the third-party library uses libC and never sees
  libstdc++, while my code uses libstdc++ and never sees libC.

My research so far suggests that these capabilities are not in the GNU
tools.  I would like to ask whether they are possible; whether there are in
fact existing ways to accomplish them; and, if not, how hard they would be
to hack, for someone without any knowledge of compiler or linker internals.
Assume that I am stuck with the third-party library and the SunOS platform.

Here is a short example that reproduces (one manifestation of) the problem
from scratch.  

% cat foo.c
#include <iostream.h>
void do_foo() { cout << "foo\n"; }
% CC -V
CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2
% CC -c -g foo.c
% ld -g -shared -o libfoo.so -soname libfoo.so foo.o /usr/lib/libC.so.5
% ldd libfoo.so
        libC.so.5 =>     /lib/libC.so.5
        libw.so.1 =>     /lib/libw.so.1
        libc.so.1 =>     /lib/libc.so.1
        libdl.so.1 =>    /lib/libdl.so.1
% cat bar.c
#include <iostream.h>
int main (int argc, char **argv) { cout << "Hello world\n"; }
% g++ -v
Reading specs from /usr/local/egcs/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.60/specs
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
% eg++ -c -g bar.c
% eg++ -o bar bar.o libfoo.so
% export LD_LIBRARY_PATH=.
% ldd bar
        libfoo.so =>     ./libfoo.so
        libm.so.1 =>     /usr/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libC.so.5 =>     /usr/lib/libC.so.5
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libw.so.1 =>     /usr/lib/libw.so.1
% ./bar
Bus Error (core dumped)
% truss ./bar 2>&1 | tail -5
    Incurred fault #5, FLTACCESS  %pc = 0xEF63D71C
      siginfo: SIGBUS BUS_ADRALN addr=0x00000045
    Received signal #10, SIGBUS [default]
      siginfo: SIGBUS BUS_ADRALN addr=0x00000045
        *** process killed ***
% gdb bar
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.5.1"...
(gdb) run
Starting program: /home/pimlott/tmp/informix_prob/bar 

Program received signal SIGBUS, Bus error.
0xef63d71c in __0fKunsafe_iosEinitP6Jstreambuf ()
(gdb) bt
#0  0xef63d71c in __0fKunsafe_iosEinitP6Jstreambuf ()
#1  0xef643b78 in __0oSistream_withassignasP6Jstreambuf ()
#2  0xef63eb4c in __0oNIostream_initctv ()
#3  0xef6566d0 in _ex_text1 ()
#4  0xef7d886c in ?? ()
#5  0xef7d8734 in ?? ()
#6  0xef7df544 in ?? ()
#7  0xef7d23a8 in ?? ()

I will note that we have found a workaround for the above example; however, it
fails in more complicated cases.  Indeed, we have tried a great number of
tweaks and variations, but each time we work around one instance of the
problem, another arises.  The common thread is a bus error somewhere in libC or
libstdc++ code.  So, we're convinced that we need to find a solution that
addresses the heart of the problem.

Thank you for any help,
Andrew

-- 
"It's like a love-hate relationship, without the love"
- Jamie Zawinski, consummate UNIX hater, on Linux