libstdc++版本冲突的解决

类似的问题出现在测试环境部署过程,当编译完成该前端解析器后,由于其依赖一些库文件,包括系统库文件libstdc++.so.6libc.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

解决办法:

  1. Run the Application on linux kernel lower than version 5.0

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.

libstdc++版本冲突的解决_第1张图片

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.

                 libstdc++版本冲突的解决_第2张图片

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:

libstdc++版本冲突的解决_第3张图片

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

libstdc++版本冲突的解决_第4张图片

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博客

你可能感兴趣的:(AP,Autosar,汽车电子,前端,java,javascript)