这个设置会给我带来麻烦吗？ libgcc 是否具有会使这种混合链接出现问题的内部状态，还是只是内联函数？
绝对是的。我刚刚花了大约一周的全天调试时间来找出在 Windows/MinGW 上调用 std::call_once 时导致我的程序崩溃的原因。这是一个简化的测试用例：
mybin.cpp:
#include <pthread.h>
#include <mutex>
#include <iostream>
extern "C" int* getVar();
void print()
{
std::cout << "Hello, var=" << *getVar() << "\n";
}
int main()
{
pthread_key_t key;
// Create first key, which will occupy the zero value, so that
// __emutls_get_address will get a nonzero one when initializing emutls_key
// (otherwise due to some C+pthread symmetries we'll not get the crash).
pthread_key_create(&key, nullptr);
std::once_flag f;
// Crash
std::call_once(f, print);
}
mylib.c:
// Make gcc emit some calls to __emutls_get_address to import
// libgcc implementing this function
static __thread int someVar;
int* getVar(void)
{
if(!someVar)
someVar=5;
return &someVar;
}
Makefile:
test: libmylib.dll mybin.o
g++ mybin.o -o test -pthread -static-libgcc -L. -lmylib
libmylib.dll: mylib.c Makefile
gcc -fPIC -shared mylib.c -o libmylib.dll
mybin.o: mybin.cpp Makefile
g++ -c mybin.cpp -o mybin.o
这里的崩溃是由于以下原因而发生的。 std::call_once 将被调用者的地址（此处为print）写入线程本地指针__once_call，其地址可通过调用__emutls_get_address 找到。这个调用直接来自.exe，所以它由static libgcc 解决（参见上面的Makefile）。接下来发生的事情是 libstdc++ 调用它的__once_proxy，然后尝试通过从 dynamic libgcc 导入的__emutls_get_address 找到__once_call 的地址，因为 libstdc++ 是一个动态库。
结果是 emutls_key，它是 libgcc 的一个静态全局变量，被初始化两次，每个 libgcc 副本（前提是 pthread_key_create 被预先调用），__once_call 在一个 TLS 中被写入副本并从另一个 TLS 中的副本中读取。随后尝试调用__once_call 会导致空指针取消引用。
以上只是我调试调查的结果，不是我故意制作的。你的经历可能更容易或更难。所以，总而言之，是的，静态和动态链接 libgcc绝对会造成麻烦。