标签: ld

我正在尝试在 GuixSD v1.0.0 和 gcc 8.3.0 上编译Xash3D。

如下所示，ld（GNU Linker）给我错误，ctr1.o 和 ctri.o 丢失。这些文件存在于 /gnu/store/{specicProgramName} 内多个目录下的其他位置，但是，令人惊讶的是，我无法建立到其他库所在的 ~/.guix_profile 的符号链接，即使具有 root 访问权限也是如此。它们有多个版本，大小不同，因此我假设它们仅与各自的程序兼容。此外。~/.guix_profile 似乎模拟了 Unix 系统的根目录，但是在 GuixSD 中，根目录和 ~/.guix_profile 都缺少 /usr，所以我不知道在哪里链接 c 对象，即使我有实际文件。

在本质上，ld找不到 crt1.o、crti.o 和 libgcc_s.so，并且很可能就像以前一样，在链接或安装这 2 个 c 对象和 libgcc 后，cmake 将停止，并出现有关其他其他错误的进一步错误依赖关系。

无论如何，这是通过以下命令打印/记录的内容（这是安装 Xash3D 的推荐方法）

sudo cmake -DHL_SDK_DIR=../hlsdk -DXASH_SDL=yes -DXASH_VGUI=yes -DCMAKE_C_FLAGS="-m32" -DCMAKE_CXX_FLAGS="-m32" -DCMAKE_EXE_LINKER_FLAGS="-m32" ../ && sudo make

-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
-- Check for working …

我ATLAS（使用 Netlib LAPACK）安装在 Docker 映像中，现在每次运行时ldconfig，都会出现以下错误：

ldconfig: Can't link /usr/local/lib//usr/local/lib/libtatlas.so to libtatlas.so
ldconfig: Can't link /usr/local/lib//usr/local/lib/libsatlas.so to libsatlas.so

当然，/usr/local/lib//usr/local/lib/libtatlas.so不存在，但我很困惑为什么它会尝试查找这个文件，因为libtatlas.so它不是符号链接：

root@cd00953552ab:/usr/local/lib# ls -la | grep atlas
-rw-r--r-- 1 root staff 15242054 Apr 27 08:18 libatlas.a
-rwxr-xr-x 1 root staff 17590040 Apr 27 08:18 libatlas.so
-rwxr-xr-x 1 root staff 17492184 Apr 27 08:18 libsatlas.so
-rwxr-xr-x 1 root staff 17590040 Apr 27 08:18 libtatlas.so

为什么会发生这种情况，有没有办法修复它/关闭此错误消息？

编辑：这是 Readelf 输出：

root@cd00953552ab:/usr/local/lib# eu-readelf -a /usr/local/lib/libatlas.so | grep SONAME …

使用该ldd命令时，有一个选项 ,-u可以

打印未使用的直接依赖项

如在线帮助中所述。

例如：

ldd  -u /bin/gcc
Unused direct dependencies:
        /lib64/libm.so.6
        /lib64/ld-linux-x86-64.so.2

什么是“未使用的直接依赖项”？为什么它们没有被使用？为什么它们是依赖关系？

在ld.so(8)的手册页中，它说

解析库依赖项时，动态链接器首先检查每个依赖项字符串以查看它是否包含斜杠（如果在链接时指定了包含斜杠的库路径名，则会发生这种情况）。如果找到斜杠，则依赖字符串被解释为（相对或绝对）路径名，并使用该路径名加载库。

如何gcc链接带有斜杠路径的库？我尝试过，-l但这似乎只适用于用于搜索各种路径的库名称，而不适用于路径参数本身。

一个后续问题：当以这种方式链接到相对路径时，相对于的路径是什么（例如，包含二进制文件的目录或运行时的工作目录）？

所有链接引导我找到搜索时的讨论使用RPATH，LD_LIBRARY_PATH和RUNPATH。RPATH已弃用，大多数讨论不鼓励使用LD_LIBRARY_PATH. RUNPATH以 开头的路径$ORIGIN允许链接到相对路径，但它有点脆弱，因为它可以被LD_LIBRARY_PATH. 我想知道相对路径是否会更健壮（因为我找不到任何讨论这个的东西，我猜不是，可能是因为路径是相对于运行时目录的）。

我在链接 Intel MKL 库以用于构建具有 MKL 支持的 Julia 时遇到问题。我在其他项目中也遇到过这个问题，但在这里我将专注于 Julia。我在/opt/intel. 我试过了：

• 跑步 /opt/intel/bin/compilervars.sh intel64
• 跑步 /opt/intel/mkl/bin/mklvars.sh intel64
• 将库 (libmkl_rt.so) 添加到 LD_LIBRARY_PATH： export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/intel/mkl/lib/intel64_lin
• /etc/ld.so.conf.d在内容中添加一个名为“mkl.conf”的文件/opt/intel/compilers_and_libraries_2019/linux/mkl/lib/intel64_lin

在我跑了最后两个之后sudo ldconfig，但没有任何变化。我怎样才能让 Make 识别这个库？

我知道 ELF 可执行文件需要有一个可见的_start子例程来开始执行。然而，据我所知，内核实际上调用了ld-linux.so（或其他一些解释器）并将执行移交给它。所以，我的问题是：

1. 谁规定了_start入口点？
2. 内核如何“调用” ld-linux.so？有稳定的API吗？_start可以这么说，一个函数？

额外问题：粗略地看一下，Glibclibdl和ld-linux.so都是同一个代码库的一部分，并且紧密地缠绕在一起（使用彼此的私有接口）。这是否意味着不可能编写一个自定义libdl的等效库来实现dlopen等？非C系统语言是否不可能生成不依赖libc且仍然可以加载*.so文件的二进制文件？

动态链接器可以通过运行一些动态链接程序或共享对象来间接运行（在这种情况下，不能将命令行选项传递给动态链接器，在 ELF 情况下，动态链接器存储在 .interp程序的一部分被执行）或直接通过运行：

/lib/ld-linux.so.* [选项] [程序 [参数]]

https://jlk.fjfi.cvut.cz/arch/manpages/man/core/man-pages/ld.so.8.en

类似的信息可以在Program Library HOWTO 中找到。

但是当我尝试时，

$ LD_DEBUG=libs /usr/lib/ld-linux.so.2 ls
     23325: find library=ls [0]; searching
     23325:  search cache=/etc/ld.so.cache
     23325: 
ls: error while loading shared libraries: ls: cannot open shared object file

$ LD_DEBUG=libs ls
     23503: find library=libcap.so.2 [0]; searching
     23503:  search cache=/etc/ld.so.cache
     23503:   trying file=/usr/lib/libcap.so.2
...

我究竟做错了什么？有没有办法ld-linux.so直接使用来运行程序？

中的 386 位和 32 位选项有什么区别ld -V？

• elf32_x86_64
• elf_i386
• i386linux
• i386pep
• i386pe

而且，我在哪里可以找到有关这些“仿真模式”的文档