gcc 4.8.5 的string问题

gcc 4.8.5及一下版本 的string 因为内部内存管理采用了COW的方式，导致了string在多线程的状态下容易崩溃。崩的很没有规律，表现就是string在赋值的时候就莫名其妙的崩了，查看堆栈，你也看不出啥。崩溃的很随机。
为了避免崩溃，我改了很多地方，从

gdb /usr/local/freeswitch/bin/freeswitch  core.78563
//然后输入
bt

当前系统环境
centos 7
gcc 4.8.5
freeswitch 1.6.20版本，使用的是gcc4.8.5编译的。
需要做的是编译第三方库给freeswitch用，动态加载so文件的方式。

方法有两种：
方式一：升级centos 7 的gcc编译环境，将freeswitch也用高版本的gcc重新编译一次。
很明显不允许。

方式二：比较麻烦。
安装scl （不做介绍）
使用命令

scl enable devtoolset-8 bash

切换到高版本的gcc编译项目。

链接的时候，添加了
-L/opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8 -lstdc++_nonshared

然后fs就能正常链接调用了。

完毕

补充。
我研究了一下 scl的环境

根据这里我找到了实际上链接的库 -lstdc++_nonshared
也就是新版本gcc 所依赖的库。

查看当前gcc 所依赖的系统库
发现它依赖的还是当前系统的库，所以该gcc能正常运行。

使用命令
nm libstdc++_nonshared.a
查看当前 .a 所提供的接口，是否有自己需要的

nm libstdc++_nonshared.a | grep ZNKSt3_V214error_category10_M_messageEi

转义接口用于将接口从混淆的转成明文的。

c++filt  _ZTIN9__gnu_cxx24__concurrence_lock_errorE

总结:
gcc 4 版本的string，有bug不建议用了。但是有的工程没办法
感觉这就是个交叉编译。