类似的问题出现在测试环境部署过程,当编译完成该前端解析器后,由于其依赖一些库文件,包括系统库文件libstdc++.so.6及libc.so,这都是系统至关重要的库文件。
但是不同系统之前此两个库的版本一般都是不同的,若直接将编译后的可执行程序及相关的库文件放到部署机器上,将很可能出现大问题,这里有个血的教训,直接将所有库文件覆盖到另一台机器,包括libstdc++.so.6及libc.so,直接导致系统被破坏,无法使用。
问题都和系统库文件相关。很明显是系统提供的库文件与我们需要的库文件版本不一致导致,其实前者也是由于系统中同时存在两个不同版本的ibstdc++.so.6。发现在安装llvm时,放置了一个ibstdc++.so.6到/usr/local/lib下,与原先系统的/usr/lib下的冲突了。
对于以上两种关于系统库的问题,该怎么处理呢?
第一种情况比较简单,统一下两个库就可以,即将/usr/local/lib下的libstdc++.so.6,libstdc++.so.6.0.*删除,拷贝/usr/lib下的libstdc++.so.6.0.*到/usr/local/lib下,并重新建立软链接libstdc++.so.6到新的libstdc++.so.6.0.*。
而对于后一种,有两个办法:一是直接在目标机器上编译安装;而另一种则是以静态库方式编译,生成一个可执行程序,不依赖其他库,具体就不详细说明了
root@j7-evm:/opt/vrte/usr/bin# . ./exmd.sh
root@j7-evm:/opt/vrte/usr/bin# ./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by ./rb-exmd)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by ./rb-exmd)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by ./rb-exmd)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by /opt/vrte/lib/librb-ecucfg-small.so)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by /opt/vrte/lib/librb-ecucfg-small.so)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by /opt/vrte/lib/librb-ecucfg-small.so)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by /opt/vrte/lib/librb-ecucfg-small.so)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by /opt/vrte/lib/librb-ecucfg-small.so)
./rb-exmd: /usr/lib/libstdc++.so.6: no version information available (required by
在TDA4上查看
root@j7-evm:~# strings /usr/lib/libstdc++.so.6 | grep GLIBC
GLIBC_2.17
GLIBC_2.18
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
在TDA4上查看
lrwxrwxrwx 1 root root 14 Aug 4 22:30 libstdc++.so -> libstdc++.so.6
lrwxrwxrwx 1 root root 19 Aug 4 22:30 libstdc++.so.6 -> libstdc++.so.6.0.28
-rwxr-xr-x 1 root root 2068744 Aug 4 22:30 libstdc++.so.6.0.28
解决办法:
The linux kernel required by AP is higher than 5.0, but the version on the target ECU is 4.19.59, so we need to do some work to make the AP adjust to the lower version linux kernel.
Copy the higher version libs required by Application
We can use “ldd” command to check all required libs by Application bins, and copy them and their soft links to the path: /opt/vrte/usr/lib
If all required libs are incomplete, maybe causing “segment fault” or “bus error".
Configure Environment Variables
LD_LIBRARY_PATH=/opt/vrte/usr/lib:/opt/vrte/lib:/lib:/usr/lib
After configuring this, Application bins will load required libs from /opt/vrte/usr/lib first.
Modify the “ld” loader for all Application processes
The process starts with the default “ld” loader (stored in the .interp field of the bin file), although the higher version libs are copied to the target folder and the Environment Variables are modified.
We can check this by “readelf” cmd:
We can use “patchelf” cmd to modify the .interp field of the bin file:
patchelf application_name --set -interpreter /opt/vrte/usr/lib/ld-linux-aarch64.so.1
readelf -l application_name
After this, all Application bins can run successfully on target.
error while loading shared libraries_San_Junipero的博客-CSDN博客
使用CMake编译时出现动态链接库错误no version information available的解决方案_o_0123的博客-CSDN博客