---
tags: 
date created: 星期三, 十一月 19日 2025, 5:03:58 下午
date modified: 星期三, 十一月 19日 2025, 5:04:15 下午
---

# 1.2.3 链接器与加载器配置 (Linker & Loader)

**1. 链接器身份与版本 (Linker Identity)**

  - **关键性**：**P1**
  - **信息解析**：
      - **组件版本**：**GNU ld (Binutils) 2.34**。这是一个相对较新的版本，完全支持 AArch64 的各种重定位类型（Relocation Types）和 LTO 插件。
      - **兼容性**：与 GCC 7.3 和 Clang 18 均能良好配合。
  - **探测命令与结果**：

    ```bash
    ld --version
    GNU ld (GNU Binutils) 2.34
    ```

**2. 二进制依赖解析 (Binary Dependency Analysis)**

  - **关键性**：**P0**
  - **信息解析**：
      - **直接依赖 (NEEDED)**：`libcudart.so.2`。
          - **深度解读**：这非常有意思。编译器（Clang）在编译时似乎模仿了 CUDA 10.2 的 ABI 行为，或者链接了伪装成 10.2 版本的存根库。这是为了让旧的 CUDA 代码无缝迁移。
      - **运行时路径 (RPATH)**：`/usr/local/corex/lib`。
          - **评价**：**优秀配置**。CMake 构建脚本通过 `CMAKE_INSTALL_RPATH` 或自动计算，将 SDK 库路径硬编码到了 ELF 文件头中。这是避免“DLL 地狱”的最佳实践。
  - **探测命令与结果**：

    ```bash
    readelf -d …/bin/main_app | grep -E "RPATH|NEEDED"
     0x0000000000000001 (NEEDED)             共享库：[libcudart.so.2]
     0x000000000000000f (RPATH)              Library rpath: [/usr/local/corex/lib]
    ```

**3. 运行时加载器解析 (Runtime Loader Resolution)**

  - **关键性**：**P0**
  - **信息解析**：
      - **解析结果**：`ldd` 显示 `libcudart.so.2` 被成功解析到了 `/usr/local/corex/lib/libcudart.so.2`。
      - **结论**：运行时链接器（ld-linux）在执行程序时，优先读取了 RPATH，找到了正确的文件，而没有去系统默认目录瞎找。程序**一定**能跑起来，不会报 `cannot open shared object file`。
  - **探测命令与结果**：

    ```bash
    ldd …/bin/main_app
    libcudart.so.2 => /usr/local/corex/lib/libcudart.so.2 (0x0000fffeda1a0000)
    ```

**4. 系统级库路径污染 (System Library Path State)**

  - **关键性**：**P2**
  - **信息解析**：
      - **环境变量**：`LD_LIBRARY_PATH` 被设置了多次重复的 `/usr/local/corex-4.3.8/lib`。
          - **风险**：虽然 RPATH 优先级高于 `LD_LIBRARY_PATH`，但这种冗余设置可能在调试（Debug）或运行其他未设置 RPATH 的工具时引发困惑。建议在 `.bashrc` 中清理去重。
      - **ld.so.conf**：系统中没有专门针对 corex 的 `.conf` 文件。这进一步凸显了 CMake 中设置 RPATH 的重要性——如果 CMake 没设 RPATH，程序必挂。
  - **探测命令与结果**：

    ```bash
    echo $LD_LIBRARY_PATH
    /usr/local/corex-4.3.8/lib:/usr/local/corex-4.3.8/lib:… (重复)
    ```