LD_LIBRARY_PATH配置错误导致启动失败时，strace通过-f -e trace=openat,stat捕获动态链接器真实加载行为：它先在错误路径反复openat失败（ENOENT），再转向系统默认路径；对比清空与保留该变量的两次strace输出，可精准定位干扰源。
用 strace 分析因 LD_LIBRARY_PATH 配置错误导致的启动失败，核心是捕获动态链接器（ld-linux.so.*）在加载共享库时的真实行为——它到底去了哪些路径、打开了哪些文件、为什么失败。这不是看最终报错文字，而是看系统调用层面发生了什么。
明确目标：盯住 openat 和 stat 系统调用
动态链接器加载库的过程本质是反复尝试 openat（或旧版 open）和 stat 某个路径下的 .so 文件。当 LD_LIBRARY_PATH 错误时，strace 会清晰显示它在错误路径里徒劳搜索，跳过正确位置。
- 运行命令时加
-e trace=openat,stat，大幅减少无关输出，聚焦关键动作 - 加上
-f参数，确保捕获子进程（比如ld-linux.so本身）的调用 - 示例：
strace -f -e trace=openat,stat /bin/bash 2>&1 | grep -E "(libtinfo|openat|stat)"
对比正常与异常路径的搜索顺序
strace 输出中，你会看到一连串 openat(AT_FDCWD, "...", ...) 调用。重点观察路径前缀：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 如果
LD_LIBRARY_PATH=/wrong/path，你会看到大量类似openat(AT_FDCWD, "/wrong/path/libtinfo.so.5", ...)的失败记录（返回-1 ENOENT） - 紧接着，它才会转向系统默认路径，如
/lib64/libtinfo.so.5或/usr/lib64/libtinfo.so.5——但此时可能已因前面干扰出错 - 若你没设
LD_LIBRARY_PATH，则几乎看不到对自定义路径的openat，直接命中系统路径
结合 ldd 和 readelf 快速定位问题根源
strace 告诉你“它去哪找了”，而 ldd 和 readelf 告诉你“它该找谁、该在哪找”：
- 先跑
ldd /bin/bash，确认它真正依赖哪个库名（例如libtinfo.so.5） - 再用
readelf -d /bin/bash | grep NEEDED看二进制里硬编码的依赖名，排除别名混淆 - 最后查真实文件：
find /lib64 /usr/lib64 -name "libtinfo.so*" 2>/dev/null，确认系统里实际存在的是libtinfo.so.6还是libtinfo.so.5
快速验证是否 LD\_LIBRARY\_PATH 干扰
不改环境变量，只用 strace 隔离测试：
- 清空变量后跟踪：
LD_LIBRARY_PATH= strace -f -e trace=openat /bin/bash -c 'exit' 2>&1 | grep libtinfo - 保留变量再跟踪：
strace -f -e trace=openat /bin/bash -c 'exit' 2>&1 | grep libtinfo - 对比两次输出中
openat的第一个成功路径是否一致。如果不一致，且异常那次总在错误目录打转，就是它的问题
