原因

使用的gcc没有找到对应的glib库。

每个版本的glib都会有改变，所以使用的时候必须匹配。

大部分是因为自己编译升级了gcc，再用新的gcc编译程序时没有找到当时匹配的类库。

查找原因

报错提示很明确了，/lib64/libstdc++.so.6中没有找到GLIBCXX_3.4.26版本内容。正常情况/lib64/libstdc++.so.6并不是具体文件，而是软连接，可以通过ls -la查看，大部分连接到当前目录下的类库，比如libstdc++.so.6.0.24。

也可以通过如下命令查看该类库下支持到哪个版本

strings /usr/lib64/libstdc++.so.6|grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_DEBUG_MESSAGE_LENGTH

可以看到是3.4.24，最后的编号24与lib库libstdc++.so.6.0.24最后的编号是一致的。

解决方法

既然lib库与glib版本是有规律的，所以理论上我们应该在系统中查找libstdc++.so.6.0.26文件（或者比26更高的类库），大部分都应该能找到，如果没找到，要么到网上下一个，要么自己再编译一遍gcc。

编译安装的类库，除非特殊指明，大部分都在/usr/local/lib64/目录下，但是编译查找的目录大部分是/usr/lib64/。所以要么指定加载路径为/usr/local/lib64/；要么把类库拷贝到/usr/lib64/

cp /usr/local/lib64/libstdc++.so.6.0.28 /usr/lib64/
mv /usr/lib64/libstdc++.so.6.0.24 /usr/lib64/libstdc++.so.6.0.24_bak
ln -s /usr/lib64/libstdc++.so.6.0.28 /usr/lib64/libstdc++.so.6

经过如上操作，再编译，理论上不会再报错