Linux readelf所示程序解释器编译时设置机制及异常咨询

• 最权威的说明来自本地系统的工具手册：执行man ld搜索--dynamic-linker参数，就能看到链接器写入ELF文件.interp段（也就是程序解释器字段）的完整规则；执行man gcc搜索相同关键字，可以看到GCC前端透传该参数给链接器的逻辑，不需要联网查外部资料。
• kbuild体系的具体实现规则直接看源码即可：swupdate这类沿用内核kbuild系统的项目，所有主机端构建工具（包括你提到的mconf）的编译、链接参数都定义在源码树的scripts/Makefile.host文件中，文件内明确写了主机程序的链接规则、参数继承逻辑，比任何外部文档都准确。

• 根因是PetaLinux（Yocto衍生版）的uninative兼容层配置bug。uninative是Yocto设计的跨发行版构建兼容机制，会主动把所有编译产物的动态解释器指向构建环境自带的glibc加载器，避免不同主机的glibc版本差异导致构建失败。你看到的超长jenkins构建路径，是PetaLinux 2021.2 eSDK打包时的已知残留问题：工具在初始化构建环境时，没有把内部自带加载器的路径替换为你本机的PetaLinux安装路径，直接把打包时的临时构建路径硬编码进了全局链接参数。
• 构建缓存污染：如果之前在加载了PetaLinux环境的shell中执行过menuconfig构建，生成的mconf.o等中间文件、kbuild缓存文件没有被清理，后续即使切换到普通shell环境重新编译，也可能沿用之前的错误链接参数。
• 构建变量被全局污染：PetaLinux环境初始化脚本会自动导出一系列主机编译相关的环境变量，这些变量中硬编码了错误的--dynamic-linker参数，只要这些变量在当前shell环境中生效，kbuild编译主机工具时就会自动携带该参数，最终生成解释器路径错误的二进制文件。

• LDFLAGS：全局链接器参数变量，只要该变量中包含--dynamic-linker=<路径>字段，所有调用ld的链接操作都会将指定路径写入ELF的解释器字段。
• HOST_LDFLAGS/LDFLAGS_FOR_HOST：kbuild、Yocto体系专用的主机端程序链接参数变量，优先级高于全局LDFLAGS，专门作用于mconf这类运行在构建主机、而非目标硬件上的工具。
• CC/HOSTCC：C编译器前端变量，部分构建配置会将动态链接器参数直接写入该变量，通过GCC前端透传给链接器。
• LD/HOSTLD：链接器路径变量，如果该变量被指向带硬编码参数的包装脚本，所有经该脚本链接的程序都会被写入指定的解释器路径。

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