静态链接stdc++fs的SO偶发filesystem::path析构崩溃问题排查

我用GCC 8.4编译了Linux共享对象libmyso.so，其中静态链接了stdc++fs。这个SO在装有更新版stdc++运行时的系统上运行时表现不稳定：有时正常工作，有时会在filesystem::path析构时崩溃。

我已明确符号版本不兼容是崩溃根源，但困惑于问题的偶发性——后来发现，只要让另一个C++共享对象先于我的SO加载，就能稳定复现崩溃。

正常加载场景 #

通过JNI加载libmyso.so时，Java程序捕获的符号绑定日志如下：

binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt10filesystem4path14_M_split_cmptsEv' [GLIBCXX_3.4.26]
//later on
binding file libmyso.so [0] to libmyso.so [0]: normal symbol `_ZNSt10filesystem4path14_M_split_cmptsEv'

此时libmyso.so使用自身静态链接的_ZNSt10filesystem4path14_M_split_cmptsEv符号，运行无异常。

异常加载场景 #

通过LD_PRELOAD强制先加载LLVM（模拟其他C++库优先加载的场景）时，符号绑定日志变为：

binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt10filesystem4path14_M_split_cmptsEv' [GLIBCXX_3.4.26]
//later on
binding file libmyso.so [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt10filesystem4path14_M_split_cmptsEv'

此时libmyso.so绑定到了系统libstdc++.so.6中的同名符号，随后触发filesystem::path析构崩溃。

核心疑问 #

为什么在异常场景下，libmyso.so没有使用自身静态链接的_ZNSt10filesystem4path14_M_split_cmptsEv符号，反而会绑定到系统库的版本？

内容的提问来源于stack exchange，提问作者Philip Miller