problems with g++, Informix ODBC lib on SunOS

Synopsis: Linking with an Informix shared library on SunOS causes a trivial C++ program that does not use that library to bus error before main() in (seemingly unrelated) C++ initialization code. The problem occurs with various versions of g++, but not Sun CC. I'm having trouble with the combination mentioned in the subject. I don't have much evidence that the problem is specific to Informix or Solaris, but since both are relatively new to me, I fear I'm missing something obvious that one of you can catch. I have narrowed down my tests to a case that works with Sun CC and fails with (various versions of) g++. If I need to include more information, please let me know as I'm desperate to track this down. I am using a libodbc.so distributed with Informix-CLI version 2.5. When I link a trivial program that uses iostreams to this library, I get a bus error. For example, asia1:try$ uname -a SunOS asia1 5.5.1 Generic_103640-21 sun4u sparc SUNW,Ultra-2 asia1:try$ /usr/local/egcs-snap/bin/c++ -v Reading specs from /usr/local/egcs-snap/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.92.34/specs gcc version egcs-2.92.34 19990103 (gcc2 ss-980609 experimental) asia1:try$ cat try.cpp #include <iostream.h> int main () { cout << "Hello world!\\n"; } asia1:try$ make /usr/local/egcs-snap/bin/c++ -g -c -I/usr/local/informix-ws/cli/include try.cpp /usr/local/egcs-snap/bin/c++ -g -o try try.o \\ -L/usr/local/informix-ws/cli/dlls -lodbc asia1:try$ echo $LD_LIBRARY_PATH /usr/local/egcs-snap/lib:/usr/local/informix-ws/cli/dlls asia1:try$ ./try Bus Error (core dumped) The gdb (4.17) backtrace is Program received signal SIGBUS, Bus error. 0xef5c6924 in __0oSostream_withassignasP6Jstreambuf () (gdb) bt #0 0xef5c6924 in __0oSostream_withassignasP6Jstreambuf () #1 0xef5beb64 in __0oNIostream_initctv () #2 0xef5d66d0 in _ex_text1 () #3 0xef7d886c in ?? () #4 0xef7d8734 in ?? () #5 0xef7df544 in ?? () #6 0xef7d23a8 in ?? () According to 'info sharedlibrary', the top three calls are in libC.so.5 (a SunOS system library), and the other four aren't in shared libraries. truss seems to indicate that the program finishes loading shared libraries, then does: munmap(0xEF6A0000, 8192) = 0 brk(0x00020AC8) = 0 brk(0x00022AC8) = 0 Incurred fault #5, FLTACCESS %pc = 0xEF5C6924 siginfo: SIGBUS BUS_ADRALN addr=0x00000001 Received signal #10, SIGBUS [default] siginfo: SIGBUS BUS_ADRALN addr=0x00000001 *** process killed *** (These are the first brk calls.) I've tried numerous variations on this theme: - SunOS 5.5 - egcs 1.1.1 (release) - g++ 2.7.2 - linking statically and dynamically to libstdc++ (in the above example, I linked dynamically; when I link statically instead by moving the .so out of the way, the backtrace goes one step further before SIGBUS'ing) - using Sun and GNU as and ld (in the above example, I used Sun's: /usr/ccs/bin/as: WorkShop Compilers 4.2 dev 13 May 1996 ld: Software Generation Utilities - Solaris/ELF (3.0) But I also tried the utilities from binutils 2.9.1.) Nothing very promising came from (many hours of) these experiments. One way to make the problem "go away" has been to - remove the iostream stuff from try.cpp - link statically to libstdc++ However, removing iostreams from our real program is not very practical. The other way, of course, is not to link with libodbc. There does not seem to be a static version of libodbc to test with. Other than this problem, our development environment seems to be in good order. We have compiled non-trivial C++ programs (that do not use libodbc) using egcs g++. I did once get a bus error from the linker ld when compiling egcs itself, but did not investigate when it went away. Finally, CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2 works fine with the exact same example. However, we do not have the Sun compiler on our development machine, and we'd much rather continue to use g++. (Just in case, can somebody tell me how current Sun's CC compiler is?) Thanks greatly for any help, Andrew (Email Cc:'s appreciated.)