libgcc_s.1 on Mac OSX 10.3.9 segfault in exception handling (maybe)

libgcc_s.1 on Mac OSX 10.3.9 segfault in exception handling (maybe)

[Oliver Goodman]

Using:
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) on
Mac OSX 10.3.9 Panther. (PPC G4)

I have a program which runs fine if I compile it like so:

oag$ g++ -g cppunithw.cc -lcppunit
oag$ ./a.out
Test::testHelloWorld : assertion
oag$

(This is the expected output.)
Whereas if I compile it like so:

oag$ g++ -g cppunithw.cc -lcppunit -lgcc_s.1
oag$ ./a.out
Test::testHelloWorldSegmentation fault

and the program hangs until I hit ^C.
The library is /usr/lib/libgcc_s.1.0.dylib and as far as I know it was 
installed with the OS.

Does anyone know immediately why something like this might happen?

OK, more information.
The program is a minimal CppUnit (testing framework) program with a 
single
test case which fails (intentionally). (I have posted on a CppUnit 
mailing list as well.)

  In fact, replace the non-test in the code sample at
   http://pantras.free.fr/articles/helloworld.html with
   void Test::testHelloWorld()
   {
	CPPUNIT_ASSERT_EQUAL(std::string("HELLO"),std::string("hello"));
   }
   and you have my program. (Incidentally the preprocessor output for 
this
   approximately 20-line, minimal test case is nearly 870k!)

Here is what gdb says.

(gdb) run
Starting program: /Users/oag/hello/a.out
Reading symbols for shared libraries +. done
Test::testHelloWorld
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0000dfd4 in parse_lsda_header(_Unwind_Context*, unsigned char const*, 
lsda_header_info*) () at /usr/local/include/cppunit/TestAssert.h:60
60                         const std::string &message )
(gdb) bt
#0  0x0000dfd4 in parse_lsda_header(_Unwind_Context*, unsigned char 
const*, lsda_header_info*) () at 
/usr/local/include/cppunit/TestAssert.h:60
#1  0x0000e284 in __gxx_personality_v0 () at 
/usr/local/include/cppunit/TestAssert.h:60
#2  0x0106d6e0 in _Unwind_RaiseException_Phase2 () at 
XmlOutputter.cpp:193
#3  0x0106da40 in _Unwind_Resume () at XmlOutputter.cpp:193
#4  0x0100a11c in CppUnit::Asserter::failNotEqual(std::string, 
std::string, CppUnit::SourceLine const&, CppUnit::AdditionalMessage 
const&, std::string) (expected=Cannot access memory at address 
0x7fffdead
) at /usr/include/gcc/darwin/3.3/c++/bits/stl_alloc.h:656
#5  0x00046e44 in void CppUnit::assertEquals<std::string>(std::string 
const&, std::string const&, CppUnit::SourceLine, std::string const&) 
(expected=@0xbffff230, actual=@0xbffff250, sourceLine={_vptr$SourceLine 
= 0x10a1e90, m_fileName = {static npos = 4294967295, _M_dataplus = 
{<allocator<char>> = {<No data fields>}, _M_p = 0x1800254 
"cppunithw.cc"}, static _S_empty_rep_storage = {0, 0, 5, 0}}, 
m_lineNumber = 27}, message=@0xbffff2a0) at 
/usr/local/include/cppunit/TestAssert.h:64
#6  0x00002cdc in Test::testHelloWorld() (this=0x300260) at 
cppunithw.cc:27
....

Yes, I am open to the idea that maybe I don't need libgcc_s.1!

The problem is of course that the actual project I am working on seems 
to need libgcc_s.1.
If I take -lgcc_s.1 out of the link flags I get:

   ld: /usr/lib/gcc/darwin/3.3/libstdc++.a(locale-inst.o) illegal 
reference to symbol: ___udivdi3   defined in indirectly referenced 
dynamic library /usr/lib/libgcc_s.1.dylib

Now it strikes me as odd that CppUnit can build and (apparently) test 
itself without
any problem, and without (as far as I can see) any reference to 
libgcc_s.1, and yet here
is a reference to it embedded in libstdc++ and staring me in the face. 
So if I really
don't need it how do I avoid that link error?

Thank you very much in advance to anyone who is able to offer any 
insight
into this, or a possible work around.

Cheers,
Oliver Goodman