C++ 与某些库链接时无法捕获异常

当链接到某个静态库时，我无法捕获可执行文件中的异常。相反，我在抛出一个'int'实例后得到terminate调用，terminate递归调用

该库包含用GCC编译的C和汇编源，以及用G++编译的C++源程序。我猜这种混合物是问题的一部分

有人能告诉我到底是什么问题吗？让我知道，如果我可以提供任何更多的信息回家在一个解释。谢谢

下面是一个简单的示例程序，当我链接到库时，它无法捕获异常。请注意，我没有从库中调用任何函数。仅仅是链接库的行为就导致了失败

baz.cpp：

#include <iostream>

using namespace std;

int main(int argc, char** argv)
{
    try {
        throw 7;
    } catch (int ex) {
        cout << "int: " << ex << endl;
    } catch (...) {
        cout << "..." << endl;
    }
}

编译编译模拟库中C++源是如何编译的：

g++ -c -falign-functions=16 -D_REENTRANT -mtune=opteron -g -O2 -fPIC -Wall -Werror -Wpointer-arith -Wreturn-type -Wswitch -Wunused -Wundef -Wno-uninitialized -Wno-format -Wno-non-virtual-dtor -Wno-sign-compare -Wwrite-strings -DTRACE_SIMPLE -Wno-strict-aliasing -g -rdynamic -D_XOPEN_SOURCE=600 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DXYZ_LITTLE_ENDIAN=1 -DXYZ_BIG_ENDIAN=0 -DXYZ=1 -DUMEM_TRACE=0 -DUSE_SYS_FLOAT -DINTEL_IPP_INLINE_MEMCHR=0 -DACCEL_TEST=1 -DXYZ -DUSE_XYZ_LIB -DACCEL_TEST=1 -o baz.o baz.cpp

静态库是用ar r和ranlib创建的

运行：

terminate called after throwing an instance of 'int'
terminate called recursively
Aborted (core dumped)

核心回溯：

#0  0x0000003ad4032625 in raise () from /lib64/libc.so.6
#1  0x0000003ad4033e05 in abort () from /lib64/libc.so.6
#2  0x0000003ad80be991 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#3  0x0000003ad80bcbd6 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x0000003ad80bcc03 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5  0x0000003ad80bcc86 in __cxa_rethrow () from /usr/lib64/libstdc++.so.6
#6  0x0000003ad80bea32 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#7  0x0000003ad80bcbd6 in ?? () from /usr/lib64/libstdc++.so.6
#8  0x0000003ad80bcc03 in std::terminate() () from /usr/lib64/libstdc++.so.6
#9  0x0000003ad80bcd22 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#10 0x0000000000400a9b in main (argc=1, argv=0x7fffffff3888) at baz.cpp:8

GCC版本：

gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) 

---

谢谢大家。问题是，在库中存在一个C文件，其中包含了一些类似C++语言/库实现功能的声明/定义。我不知道为什么会包含这个文件，因为删除它并重新编译库并没有引起任何问题，至少is还没有。。。。示例程序能够在与重新编译的库链接时捕获异常

如果有人想发布为什么这些声明/定义的存在导致异常无法被捕获，请放心，我可能会接受您的回答。我将试图找出为什么这个文件被包括在开始。如有任何建议，将不胜感激

以下是该文件的内容：

int __gxx_personality_v0(void);

int __gxx_personality_v0(void)
{
        return 1;
}

void __cxa_pure_virtual(void);

void __cxa_pure_virtual(void)
{
}

void _ZTVN10__cxxabiv117__class_type_infoE(void);
void _ZTVN10__cxxabiv120__si_class_type_infoE(void);
void _ZTVN10__cxxabiv121__vmi_class_type_infoE(void);

void _ZTVN10__cxxabiv117__class_type_infoE(void) {}
void _ZTVN10__cxxabiv120__si_class_type_infoE(void) {}
void _ZTVN10__cxxabiv121__vmi_class_type_infoE(void) {}

---

我不熟悉那个特定的编译器，但它可能假设C函数是非递归的。它名为std:：terminate这一事实意味着它推断出了一个noexcept。基本上，确保C函数不会出现异常。如果没有额外的库，它工作得很好：因此您的代码示例不会真正模拟使用库时发生的情况@VoidStar很好地说明了这个库可能有什么问题。如果你没有实际运行链接库中的代码，那么应该没有什么区别。。。我假设库中的一个函数是C函数，没有异常可以通过它产生！！任何这样的功能。也许有什么看不见的事情发生了。。。？另外，您可以从/usr/lib64/libstdc++.so.6查看cxa中90x0000003AD80BCD22的源代码吗？它可能会提示为什么它认为调用STD：：终止是合适的。你不能做的是把一个回调函数传递给一个C++函数，然后让那个回调抛出一个异常。如果你想让它工作，你必须修改C代码，用F-异常来构建它。可能库中有C启动，它不应该这样，你就不会有C++启动了。要对此进行调试，您可以使用原始对象文件而不是库，并找出哪一个触发了问题。

int __gxx_personality_v0(void);

int __gxx_personality_v0(void)
{
        return 1;
}

void __cxa_pure_virtual(void);

void __cxa_pure_virtual(void)
{
}

void _ZTVN10__cxxabiv117__class_type_infoE(void);
void _ZTVN10__cxxabiv120__si_class_type_infoE(void);
void _ZTVN10__cxxabiv121__vmi_class_type_infoE(void);

void _ZTVN10__cxxabiv117__class_type_infoE(void) {}
void _ZTVN10__cxxabiv120__si_class_type_infoE(void) {}
void _ZTVN10__cxxabiv121__vmi_class_type_infoE(void) {}