Yocto SDK中SO/ELF文件依赖冲突的解决方法咨询

问题背景 #

将Yocto从Dunfell版本升级至Kirkstone后，常规镜像运行正常，但使用commonapi 3.1.12.4构建SDK时，出现GLIBC版本兼容问题：原项目适配GLIBC 2.31，而Kirkstone默认搭载GLIBC 2.35，报错显示nativesdk-capicxx-core缺少libpthread.so.0、libdl.so.2及多个GLIBC版本符号依赖。

已尝试的操作：

• 使用INSANE_SKIP或do_package_qa[noexec]可跳过单个包的依赖检查，但制作SDK时无法生效；
• 用patchelf修改ELF文件移除部分依赖，但仍有依赖来自eclipse_1605.so，且DNF会在制作SDK前检查所有依赖；
• 编辑RPM的.spec文件无效，因为依赖是从SO/ELF文件内部读取的。

问题解答 #

1. 是否可让DNF在制作SDK时跳过依赖检查？ #

可以通过配置禁用SDK构建时的DNF依赖检查。在local.conf或对应recipe中添加以下配置：

SDK_BUILD_DEPENDENCY_CHECK = "0"

该变量会控制SDK构建阶段是否执行依赖校验，设为0即可跳过DNF的检查环节。同时可针对目标包补充QA跳过配置：

INSANE_SKIP_nativesdk-capicxx-core += " ldflags libs"

确保SDK构建流程中跳过该包的依赖相关QA检查。

2. SDK中能否忽略依赖？ #

可以在构建阶段通过recipe配置实现，不推荐修改已生成的SDK：

• 在nativesdk-capicxx-core的recipe中，强制清空依赖声明：

  DEPENDS_${PN} = ""
  RDEPENDS_${PN} = ""
  

• 或者允许包为空依赖：

  ALLOW_EMPTY_${PN} = "1"
  

  这样构建时会跳过该包的依赖校验，生成的SDK也不会强制要求这些依赖。

3. 在/lib下添加旧版GLIBC依赖目录并修改ld.so.conf会引发冲突，是否有替代方案？ #

推荐采用依赖路径隔离方案，无需修改系统/lib目录：

• 构建SDK时，将旧版GLIBC（2.31）打包到SDK的独立目录，比如${SDKPATH}/glibc-compat/lib；
• 在SDK的environment-setup-*配置文件中添加：

  export LD_PRELOAD="${SDKPATH}/glibc-compat/lib/libc.so.6 ${SDKPATH}/glibc-compat/lib/libpthread.so.0 ${SDKPATH}/glibc-compat/lib/libdl.so.2"
  

  利用LD_PRELOAD强制加载指定旧版库，避免与系统GLIBC冲突；
• 也可针对特定二进制文件用patchelf设置专属rpath：

  patchelf --set-rpath "${SDKPATH}/glibc-compat/lib:$ORIGIN" ${SDKPATH}/path/to/nativesdk-capicxx-core/bin/your-binary
  

  让目标文件优先从隔离目录加载依赖。

4. 能否指定特定ELF文件/包仅从特定目录查找依赖？ #

有两种可靠实现方式：

• 针对单个ELF文件修改rpath：用patchelf工具直接修改目标文件的依赖搜索路径：

  patchelf --set-rpath "/path/to/custom/lib:$ORIGIN" /path/to/your/elf/file
  

  $ORIGIN表示ELF文件所在目录，可保证相对路径的正确性；
• 在recipe中全局配置：在nativesdk-capicxx-core的recipe中添加编译参数，将指定目录写入所有生成文件的rpath：

  LDFLAGS_${PN} += "-Wl,-rpath,${SDKPATH}/custom/lib"
  

  这样构建出的包会默认优先从指定目录查找依赖。

内容的提问来源于stack exchange，提问作者ZBT248