链接libthrift.so出现带“__cxx11”的undefined symbol的问题解决

一、问题描述

项目中一个C++程序要读写hbase的数据，按thrift接口规范编写好代码，在windows平台该程序运行正常。但在移植到linux平台后，在编译链接时一直报undefined symbol错误，即使采用其它技术手段绕过这个错通过编译链接，运行时仍会出错。

经检查，出错是因为一个模块（lib_hbase_reader.so）中调用的三个接口与libthrift-0.10.0.so中提供的接口不一致引起的，使用ldd得到的信息为：

$ldd -r libhbase_reader.so
...
libthrift-0.10.0.so => /usr/local/lib64/libthrift-0.10.0.so (0x00007f91ea5fb000)
...

undefined symbol: _ZN6apache6thrift5async25TConcurrentClientSyncInfo10getPendingERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS0_8protocol12TMessageTypeERi (./lib_hbase_reader.so)
undefined symbol: _ZN6apache6thrift9transport7TSocketC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi (./lib_hbase_reader.so)
undefined symbol: _ZN6apache6thrift5async25TConcurrentClientSyncInfo13updatePendingERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS0_8protocol12TMessageTypeEi (./lib_hbase_reader.so)

以其中的getPending为例，在libthrift-0.10.0.so中提供的接口形式却是：

$ nm -a /usr/local/lib/libthrift-0.10.0.so | grep getPending
0000000000046b10 T _ZN6apache6thrift5async25TConcurrentClientSyncInfo10getPendingERSsRNS0_8protocol12TMessageTypeERi

二、出错原因

从出错信息看，貌似是两个so对某个类型产生了分歧，一个按__cxx11...，而另一个按基本类型。

看起来简单，解决之路却异常艰难，一度到了山穷水尽的地步。隔了一段时间后不得不重新面对，又经历了很多艰难险阻，终于找到原因，原来与编译所用的gcc版本密切相关：

lib_hbase.reader.so与libthrift-0.10.0.so不是同一个版本的gcc编译生成的，前一个因最近生成，使用的是gcc 7.3.0，而后一个是从svn库拿到的老版本，使用的是gcc 4.8.5。
这就over了？远远没有，运行程序的服务器如果不是同一版本，运行时一样出错！必须将运行服务器的gcc也升级到相同版本。

解决过程中还出现了种种小陷阱，不过最终都解决了。

三、关键步骤之：升级gcc

Linux默认的gcc版本是4.8.5，如果编译某个模块时用的是高版本gcc，就需将所有相关Linux服务器的gcc都进行升级。这里以7.3.0为例。

# wget http://mirrors.kernel.org/gun/gcc/gcc-7.3.0/gcc-7.3.0.tar.gz
# tar -xvf gcc-7.3.0.tar.gz
# cd gcc-7.3.0
# ./contrib/download_prerequisites
# mkdir build
# cd build
# ../configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
# make
# make install

make的时间会很长，可用make -j4开四个任务加快速度。/contrib/download_prerequisites对运行机不是必须的，这对内网环境是个好消息。

升级完后，还需要更新/usr/bin/目录下的c++, g++, gcc*等文件，以及libstdc++.so.6。

# mv /usr/bin/c++ /usr/bin/c++.bak
# mv /usr/bin/g++ /usr/bin/g++.bak
# mv /usr/bin/gcc /usr/bin/gcc.bak
# mv /usr/bin/gcc-ar /usr/bin/gcc-ar.bak
# mv /usr/bin/gcc-nm /usr/bin/gcc-nm.bak
# mv /usr/bin/gcc-ranlib /usr/bin/gcc-ranlib.bak
# ln -s /usr/local/bin/c++ /usr/bin/c++
# ln -s /usr/local/bin/g++ /usr/bin/g++
# ln -s /usr/local/bin/gcc /usr/bin/gcc
# ln -s /usr/local/bin/gcc-ar /usr/bin/gcc-ar
# ln -s /usr/local/bin/gcc-nm /usr/bin/gcc-nm
# ln -s /usr/local/bin/gcc-ranlib /usr/bin/gcc-ranlib

# rm /lib64/libstdc++.so.6
# ln -s /usr/local/lib64/libstdc++.so.6.0.24 /lib64/libstdc++.so.6

这里采用的是“旧文件改名+建软连接”的方式，还有一种方式是“拷贝新文件覆盖”的方式。

完成后查看gcc版本：

# gcc -v

四、关键步骤之：重新编译libthrift

如果gcc已升级，必须重新编译libthrift，假设为0.10.0版，已有源码包，不必再下载。

# tar -zxvf libthrift-0.10.0.tar.gz
# cd  libthrift-0.10.0
# ./configure --with-cpp --with-boost --without-python CPPFALGS=-std=c++11
# ./make
# ./make install

特别注意：configure时必须加“CPPFALGS=-std=c++11”选项，否则错误依旧。在用gcc 7.3.0编译时，会出很多警告信息，但貌似没影响。

libthrift依赖的libboost则不需要重新编译。

原文地址：https://www.cnblogs.com/wggj/p/10333394.html

时间： 2024-08-05 14:13:11