之前用的好好的gampping建图功能包,今天突然不能用了,运行报错如下:
/opt/ros/noetic/lib/gmapping/slam_gmapping: symbol lookup error: /opt/ros/noetic/lib/gmapping/slam_gmapping: undefined symbol: _ZN8GMapping14sampleGaussianEdm
process[move_base-2]: started with pid [16541]
[slam_gmapping-1] process has died [pid 16540, exit code 127, cmd /opt/ros/noetic/lib/gmapping/slam_gmapping __name:=slam_gmapping
核心报错信息是slam_gmapping: symbol lookup error 和slam_gmapping: undefined symbol: _ZN8GMapping14sampleGaussianEdm
一、报错原因探索
即未定义符号错误undefined symbol类报错,一般是依赖配置错误导致,采用c++filt工具来对符号进行解析,在终端执行以下语句:
c++filt _ZN8GMapping14sampleGaussianEdm
得到的结果为:
GMapping::sampleGaussian(double, unsigned long)
该报错信息表明GMapping命名空间中的一个函数sampleGaussian (double, unsigned long) 在运行时找不到,导致了符号查找错误。
最初,我认为是依赖文件缺失或者版本不匹配问题,于是尝试使用以下指令检查和更新gmapping库及其依赖
sudo apt update
sudo apt install ros-noetic-gmapping
rosdep update
rosdep install gmapping
然而却提示所以依赖已经安装了,网上有资料说可以使用以下指令检查是否有其他版本的gmapping包存在
https://wenku.csdn.net/answer/svf5xma0ty
rospack list-names | grep gmapping
返回的结果为,即没有其他包,也不是这个原因
gmapping
openslam_gmapping
网上又有资料说通过源码安装在自己的工作空间,然后编译可以解决这个问题:
https://blog.csdn.net/zhaohaowu/article/details/124788996
于是我下载了slam_gmapping和openslam_gmapping两个包的源码,并在工作空间成功完成了编译,但是该错误依然存在…
哎…,貌似陷入了困局,没办法,只能继续刨根问底了,我使用以下指令检查了slam_gmapping依赖哪些具体的库文件
ldd /home/gly/catkin_ws/devel/lib/gmapping/slam_gmapping
结果如下:
linux-vdso.so.1 (0x00007fff3dbca000)
libgridfastslam.so => /home/gly/catkin_ws/devel/lib/libgridfastslam.so (0x00007fa3751d7000)
libtf.so => /opt/ros/noetic/lib/libtf.so (0x00007fa3751a7000)
libmessage_filters.so => /opt/ros/noetic/lib/libmessage_filters.so (0x00007fa37519f000)
libroscpp.so => /opt/ros/noetic/lib/libroscpp.so (0x00007fa374fef000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa374f8d000)
libroscpp_serialization.so => /opt/ros/noetic/lib/libroscpp_serialization.so (0x00007fa374f86000)
librosbag_storage.so => /opt/ros/noetic/lib/librosbag_storage.so (0x00007fa374f00000)
librosconsole.so => /opt/ros/noetic/lib/librosconsole.so (0x00007fa374e9d000)
librostime.so => /opt/ros/noetic/lib/librostime.so (0x00007fa374e71000)
libcpp_common.so => /opt/ros/noetic/lib/libcpp_common.so (0x00007fa374e63000)
libboost_thread.so.1.71.0 => /lib/x86_64-linux-gnu/libboost_thread.so.1.71.0 (0x00007fa374e37000)
libscanmatcher.so => /home/gly/catkin_ws/devel/lib/libscanmatcher.so (0x00007fa374e07000)
libutils.so => /home/gly/motionplanning_ws/devel/lib/libutils.so (0x00007fa374df9000)
libsensor_odometry.so => /home/gly/catkin_ws/devel/lib/libsensor_odometry.so (0x00007fa374df3000)
libsensor_range.so => /home/gly/catkin_ws/devel/lib/libsensor_range.so (0x00007fa374de2000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa374c00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa374ab1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa374a94000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3748a2000)
libsensor_base.so => /home/gly/catkin_ws/devel/lib/libsensor_base.so (0x00007fa37489d000)
libtf2_ros.so => /opt/ros/noetic/lib/libtf2_ros.so (0x00007fa3747e5000)
libtf2.so => /opt/ros/noetic/lib/libtf2.so (0x00007fa3747a8000)
libxmlrpcpp.so => /opt/ros/noetic/lib/libxmlrpcpp.so (0x00007fa374784000)
libboost_chrono.so.1.71.0 => /lib/x86_64-linux-gnu/libboost_chrono.so.1.71.0 (0x00007fa374774000)
libboost_filesystem.so.1.71.0 => /lib/x86_64-linux-gnu/libboost_filesystem.so.1.71.0 (0x00007fa374756000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa37539f000)
libclass_loader.so => /opt/ros/noetic/lib/libclass_loader.so (0x00007fa374729000)
libroslib.so => /opt/ros/noetic/lib/libroslib.so (0x00007fa37470e000)
libtinyxml2.so.6 => /lib/x86_64-linux-gnu/libtinyxml2.so.6 (0x00007fa3746f7000)
libroslz4.so => /opt/ros/noetic/lib/libroslz4.so (0x00007fa3746f0000)
libconsole_bridge.so.0.4 => /lib/x86_64-linux-gnu/libconsole_bridge.so.0.4 (0x00007fa3746e8000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fa3746d5000)
librosconsole_log4cxx.so => /opt/ros/noetic/lib/librosconsole_log4cxx.so (0x00007fa3746b5000)
librosconsole_backend_interface.so => /opt/ros/noetic/lib/librosconsole_backend_interface.so (0x00007fa3746b0000)
liblog4cxx.so.10 => /lib/x86_64-linux-gnu/liblog4cxx.so.10 (0x00007fa3744d2000)
libboost_regex.so.1.71.0 => /lib/x86_64-linux-gnu/libboost_regex.so.1.71.0 (0x00007fa3743d2000)
libactionlib.so => /opt/ros/noetic/lib/libactionlib.so (0x00007fa3743af000)
libPocoFoundation.so.62 => /lib/x86_64-linux-gnu/libPocoFoundation.so.62 (0x00007fa3741f7000)
librospack.so => /opt/ros/noetic/lib/librospack.so (0x00007fa3741a8000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fa374187000)
libapr-1.so.0 => /lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007fa37414c000)
libaprutil-1.so.0 => /lib/x86_64-linux-gnu/libaprutil-1.so.0 (0x00007fa37411e000)
libicui18n.so.66 => /lib/x86_64-linux-gnu/libicui18n.so.66 (0x00007fa373e1f000)
libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007fa373c39000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa373c33000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa373c29000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa373bb4000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa373b98000)
libboost_program_options.so.1.71.0 => /lib/x86_64-linux-gnu/libboost_program_options.so.1.71.0 (0x00007fa373b09000)
libpython3.8.so.1.0 => /lib/x86_64-linux-gnu/libpython3.8.so.1.0 (0x00007fa3735b3000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fa3735aa000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fa37356d000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fa37353f000)
libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x00007fa371a7e000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fa371a79000)
然后使用nm 工具来查看特定库中定义的符号,当使用如下语句检查依赖中的libgridfastslam.so文件时,
nm -C /home/gly/catkin_ws/devel/lib/libgridfastslam.so | grep sampleGaussian
返回结果为:
U GMapping::sampleGaussian(double, unsigned long)
该结果表明GMapping::sampleGaussian(double, unsigned long) 函数在 libgridfastslam.so 库中被标记为 “U”,这意味着它是一个未定义(Undefined)的符号。即 libgridfastslam.so 库引用了这个符号,但并没有在该库或其任何依赖的库中实现它。换句话说,libgridfastslam.so 需要这个函数,但它不知道这个函数的代码在哪里,这就是为什么报错的原因。
通过查找在gmapping功能包的slam_gmapping.cpp文件的如下语句中调用了GMapping::sampleGaussian
// Call the sampling function once to set the seed.
GMapping::sampleGaussian(1,seed_);
该函数在openslam_gmapping功能包的stat.cpp中定义和实现,其源码如下:
double sampleGaussian(double sigma, unsigned long int S) {
/*
static gsl_rng * r = NULL;
if(r==NULL) {
gsl_rng_env_setup();
r = gsl_rng_alloc (gsl_rng_default);
}
*/
if (S!=0)
{
//gsl_rng_set(r, S);
srand48(S);
}
if (sigma==0)
return 0;
//return gsl_ran_gaussian (r,sigma);
return pf_ran_gaussian (sigma);
}
–
这函数这不在这好好的嘛,,,,为啥找不到…,服了…,如果是编译顺序的问题,我在编译的时候特意先编译的openslam_gmapping功能包,再编译的gmapping功能包,按理说不应该出现这个问题呀。。。。。。。。。。。。。。。。。。。。。。。。
接着,我使用如下指令查找了同样位于stat.cpp中,且与sampleGaussian函数位于同一命名空间的pf_ran_gaussian函数,结果为空,如下所示:
nm -C /home/gly/catkin_ws/devel/lib/libgridfastslam.so | grep pf_ran_gaussian
这说明什么? 说明很有可能我们之前的判读是错误的,undefined symbol: _ZN8GMapping14sampleGaussianEdm所需的内容,根本不是由libgridfastslam.so文件提供,很明显,函数程序并没有链接到该文件,而是其他文件。
我们执行以下指令,进入到openslam_gmapping功能包所在的工作空间存放链接文件的路径下 (大家根据自己的存放路径进行修该)
cd /home/gly/catkin_ws/devel/lib/
然后使用以下指令查找,sampleGaussian函数位于那个链接文件中。结果如下:
nm -C *.so | grep sampleGaussian
可以发现其存在于三个文件中,且在一个文件中定义,这是个好消息,接着我们执行以下指令,来具体查看有定义的链接文件是那个
for so in *.so; do
echo "Checking $so ..."
nm -C $so | grep GMapping::sampleGaussian && echo "Found in $so"
done
结果如下:
很好,我们已经成功锁定了这个名为libutils.so的链接文件,接下来我再使用同样位于stat.cpp中另一个名为pf_ran_gaussian函数来验证一下stat.cpp对应的有效链接文件是否为libutils.so,执行以下指令
for so in *.so; do
echo "Checking $so ..."
nm -C $so | grep GMapping::pf_ran_gaussian&& echo "Found in $so"
done
非常好,现在基本上已经确定slam_gmapping: undefined symbol: _ZN8GMapping14sampleGaussianEdm 问题的原因出在libutils.so文件,现在该文件已经确定是存在,且其路径在ROS的环境变量中,那大概率就是文件冲突原因导致的了,我直接在整个计算机范围为搜索该文件
非常好,非常好,/home/gly/motionplanning_ws中的内容是我近期新加入的,且其环境变量的优先级高于openslam_gmapping功能包所在的工作空间/home/gly/catkin_ws环境变量的优先级,这样就说的通,为啥gampping建图突然就不能用了,因为,我在一个具有更高优先级的工作空间环境变量中新加入的程序中也存在一个libutils.so文件,且与openslam_gmapping功能包所需的文件不是同一个文件,这样程序在运行时,优先搜索到了这个错误的同名链接文件,这个文件中当然没有所需的sampleGaussian等函数的相关内容。
二、解决方法
找到原因后,接下来的解决方法就很简单了,/home/gly/motionplanning_ws中的内容是我需要的,显然并不能采取删除来解决该问题,比较理想的方式是调整工作空间优先级,根据个人的情况,可以采用临时调整和长久调整两种模式
1、在调整之前还有两个非常重要的概念需要区分: ROS_PACKAGE_PATH 和LD_LIBRARY_PATH
LD_LIBRARY_PATH
和 ROS_PACKAGE_PATH
是两个不同的环境变量,它们在 UNIX 和 Linux 系统中用于不同的目的,尤其是在使用 ROS(Robot Operating System)时。
LD_LIBRARY_PATH
- 用途:
LD_LIBRARY_PATH
是一个环境变量,用于指定动态链接器搜索动态库(.so
文件)时的目录路径。当程序运行时,动态链接器会在这些路径中查找所需的动态库文件。 - 作用范围:它影响的是程序运行时的库加载行为,不仅限于ROS,适用于所有使用动态库的程序。
- 特点:修改
LD_LIBRARY_PATH
可以解决库版本冲突或确保程序使用特定版本的库,但是不当的使用可能会导致系统或其他程序的运行问题。
ROS_PACKAGE_PATH
- 用途:
ROS_PACKAGE_PATH
是一个特定于 ROS 的环境变量,用于指示 ROS 系统在哪些目录下查找 ROS 包。这个变量包含了一系列目录,ROS 工具(如roscd
,rospack
,rosrun
等)会在这些目录中搜索包。 - 作用范围:它仅影响 ROS 工具和运行时系统寻找和管理 ROS 包的行为,与动态链接库的加载无关。
- 特点:正确设置
ROS_PACKAGE_PATH
对于 ROS 节点和程序能够找到其依赖的包至关重要。它确保了 ROS 工具和运行时环境可以在你的工作空间中找到并正确使用 ROS 包。
总结
- LD_LIBRARY_PATH
关注的是程序运行时动态库的加载,它告诉动态链接器在哪些额外的目录中查找库文件。- ROS_PACKAGE_PATH
关注的是 ROS 环境中包的查找,它告诉 ROS 在哪些目录中查找 ROS 包。
两者都是环境变量,但服务于不同的目的,分别影响动态库的加载和ROS包的查找。在使用 ROS 进行开发时,正确配置这两个环境变量对于确保程序的正确编译和运行非常重要。
所以我们需要调节的事LD_LIBRARY_PATH,而不是ROS_PACKAGE_PATH!!!
2、方法一:临时调整
在你想要运行gmapping建图的终端执行以下指令(工作空间路径需要根据自己情况修改),来仅在该终端下将gmapping建图所在的工作空间
export LD_LIBRARY_PATH=/home/gly/catkin_ws/devel/lib:$LD_LIBRARY_PATH
这个命令将 /home/gly/catkin_ws/devel/lib 添加到 LD_LIBRARY_PATH 的开头,确保了动态链接器首先搜索这个目录。请注意,这种更改只对当前终端会话有效。关闭终端或开启新的会话都将丢失这个设置。
3、方法二:长久调整
如果你希望这个设置在所有会话中都有效,可以通过修改.bashrc文件中关于环境变量的配置,你可以选择手动打开该文件,在文件末尾加入如下语句,然后保存
export LD_LIBRARY_PATH=/home/gly/catkin_ws/devel/lib:$LD_LIBRARY_PATH
当然,你可以选择直接在终端执行如下语句,自动将其添加到.bashrc文件中
echo 'export LD_LIBRARY_PATH=/home/gly/catkin_ws/devel/lib:$LD_LIBRARY_PATH' >> ~/.bashrc
使用如下指令,分别打印出修改前后的动态链接库路径如下所示
然后,我成功运行了gmapping建图,如下所示,问题成功解决
注:本文还存在另外一个更加简洁,概括性总结性更强的版本,如下所示:
https://blog.csdn.net/qq_44339029/article/details/137341737