Yocto Dunfell交叉编译32位armhf程序时runtime linker设置错误问题

1. 编译阶段决定interpreter选择的因素 #

runtime linker（interpreter）的路径由链接时的-dynamic-linker参数直接决定：

• 正常场景下不需要手动指定该参数：使用GCC作为链接前端（即直接用gcc命令完成最终链接步骤）时，GCC会根据目标架构、ABI、sysroot配置自动填充对应平台的正确interpreter路径，同时还会自动链接glibc提供的启动目标文件（crt1.o/crti.o/crtn.o等），这就是简单Hello World程序可以自动生成正确配置的原因。
• 你当前的编译流程直接调用了arm-poky-linux-gnueabi-ld完成最终链接，ld本身没有内置平台对应的interpreter路径默认值，也不会自动链接glibc启动文件，因此会使用默认的通用/usr/lib/ld.so.1作为interpreter，同时你会遇到找不到程序入口的报错，只能手动加--entry main规避，这两个问题完全同源。

2. 香橙派系统不存在/usr/lib/ld.so.1的原因 #

不同ARM ABI对应的glibc runtime linker路径有明确规范：

• 你使用的armhf（硬浮点ARMv7）架构，标准glibc runtime linker路径为/lib/ld-linux-armhf.so.3，Yocto构建armhf根文件系统时，只会打包对应ABI的ld.so，不会包含旧的软浮点ABI使用的/usr/lib/ld.so.1。
• /usr/lib/ld.so.1是旧ARM软浮点ABI、非armhf发行版使用的interpreter路径，和你当前使用的armhf架构不兼容。

3. 修复方案 #

你对ARM架构的认知没有错误，问题完全来自链接流程配置错误，修复方案有两种，优先选第一种：

• 方案1（推荐）：放弃直接调用ld做最终链接，改用GCC作为链接前端
  将最终链接步骤从调用arm-poky-linux-gnueabi-ld改为调用arm-poky-linux-gnueabi-gcc，GCC会自动传递所有正确的链接参数，包括正确的interpreter路径、glibc启动文件链接，你之前手动加的--entry main参数也可以完全删除，不需要额外调整其他参数。
• 方案2：手动给ld补充缺失参数
  如果必须直接调用ld，需要额外增加两个配置：
  • 加链接参数指定正确的interpreter：-dynamic-linker /lib/ld-linux-armhf.so.3
  • 手动链接sysroot下的glibc启动文件crt1.o/crti.o/crtn.o，无需再手动指定--entry main

修复完成后可以用readelf -l my-exec | grep interpreter命令验证interpreter路径是否正确。

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