Date: Sun, 1 Feb 2009 10:31:01 -0500 From: Ryan Stone <rysto32@gmail.com> To: freebsd-hackers@freebsd.org Cc: xorquewasp@googlemail.com Subject: gcc 4.3.2 libgcc_s.so exception handling broken? Message-ID: <bc2d970902010731u26a12b29t985ee4e2d8ac12da@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I saw a very similar thing happen when we moved to gcc 4.3 on a 6.1 system. The problem ended up being that we were linking everything, including shared objects, against a static libgcc. This meant that when a C++ program loaded a C++ shared object, there'd be two copies of the exception handling code in the process. What happened was the the executable registered all its exception handlers with the copy in the excecutable, and then loaded the shared object. When it raised an exception, it called the exception handling code in the shared object, which didn't know anything about the exception handlers in the executable, so it couldn't find them, so it called terminate(). The solution was to link everything against a dynamic libgcc, so there'd only be one copy of the exception handling code. Your problem may be similar. I doubt that you're statically linking libgcc in, but if you are, that's you're problem. My guess is that either your executable, or another shared library that your exectuable uses, is linking against a different libgcc_s.so, which would cause the same problem(multiple copies of the exception handling code). ldd should be able to tell you if this is the case. Ryan Stone
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bc2d970902010731u26a12b29t985ee4e2d8ac12da>