链接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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 如果在Windows 11下使用CLion链静态库时出现`undefined_reference`错误,可能是由于以下原因之一: 1. 未正确设置库的路径和名称。在CMakeLists.txt文件中,你需要确保正确指定库文件的路径和名称。例如,如果你的库文件名为`mylib.lib`,则可以使用以下代码将其链到你的项目中: ``` link_directories(/path/to/library) target_link_libraries(your_target_name mylib) ``` 其中,`/path/to/library`是你的库文件路径,`mylib`是你的库文件名称。 2. 库文件被编译为与你的项目不兼容的架构。例如,如果你的项目是32位应用程序,但你的库文件是64位编译的,则会出现错误。你需要确保库文件与你的项目使用相同的架构。 3. 库文件的链顺序不正确。如果你的项目依赖于多个库文件,你需要确保它们以正确的顺序链。例如,如果库A依赖于库B,则库B应该先链。 4. 库文件中缺少所需的符号。如果库文件中缺少所需的符号,则会出现`undefined_reference`错误。你需要确保库文件中包含所有所需的符号。 可以尝试按照上述步骤进行排查,查找并解决问题。 ### 回答2: 在 Windows 11 上使用 CLion 连静态库时出现 undefined_reference 错误,这通常是由于缺少库文件、编译参数不正确或者库函数的链顺序不正确引起的。 首先,我们需要确保在 CLion 项目的 CMakeLists.txt 文件中正确指定了静态库的路径。在 add_executable() 函数中,需要添加链静态库的命令,如:target_link_libraries(项目名称 -l库名称),其中项目名称为你的项目名称,库名称为要链的静态库文件名(不含扩展名)。 其次,要确保在静态库的链顺序中,库文件的位置应排在使用该库的文件之后。因为链器是按照从左到右的顺序加载库文件,如果库文件的位置不正确,链器将无法找到所需的函数定义。 另外,如果你使用的静态库依赖其他库文件,你还需要在 CMakeLists.txt 文件中指定依赖的库文件路径。你可以使用link_directories()函数指定其他库文件的路径。 最后,如果你的静态库是使用其他编译工具生成的,可能存在编译参数不兼容的问题。你需要确保静态库和你的项目使用的编译器版本兼容,并且链参数和编译参数一致。 总结来说,解决 CLion 在 Windows 11 下链静态库出现 undefined_reference 错误的方法是:正确指定库文件路径、检查库文件的链顺序、指定依赖的库文件路径,并确保编译器和链参数兼容。如果问题仍然存在,可以进一步检查库文件是否正确编译,或者尝试重新生成库文件。 ### 回答3: 在Windows 11下使用CLion链静态库时出现undefined_reference错误是因为编译器无法找到库文件中定义的某些函数或变量的实现。要解决此错误,您可以采取以下步骤: 1. 确认您已正确设置静态库路径。在CLion中,您可以通过在CMakeLists.txt文件中添加以下行来设置静态库路径: ``` link_directories(/path/to/static/library) ``` 将`/path/to/static/library`替换为实际的静态库路径。 2. 确认您已正确链静态库。在CMakeLists.txt文件中,通过添加以下行来链静态库: ``` target_link_libraries(your_executable_name library_name) ``` 将`your_executable_name`替换为您的可执行文件名称,将`library_name`替换为要链的静态库名称。 3. 检查是否包含了库的头文件。在您的源代码文件中,确保包含了静态库的头文件,通过添加以下行: ``` #include <library_header_file.h> ``` 将`library_header_file.h`替换为实际的静态库头文件。 4. 如果您在编译时使用了优化标志,请尝试禁用优化。有时,优化标志可能会导致链错误。您可以在CMakeLists.txt文件中添加以下行以禁用优化: ``` set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0") ``` 这将禁用调试模式下的优化。 5. 如果上述步骤仍然无法解决问题,可能是您的静态库存在问题,您可以尝试重新构建静态库或使用其他版本的静态库。 希望以上步骤能够帮助您解决在Windows 11下使用CLion链静态库出现undefined_reference错误的问题

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值