链接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则不需要重新编译。