我面临一个耗费我大量时间的问题。我尝试使用 ld 链接器和 c 函数链接我的目标文件(用 nasm 编译的小程序)。我搜索了很多,发现加载所有 c 库的解决方案是将 -lc 作为选项传递给 ld,这确实消除了所有警告和错误并生成了我的可执行文件。问题是当我尝试运行我的程序时总是出现“没有这样的文件或目录”错误。
我在网上搜索了很多,找到了这个有用的答案询问 Ubuntu 答案但不幸的是,这并没有解决我的问题。
这里有一些信息:
> file main
returned:
main: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, not stripped
该程序版本为64位,解释器按照“文件命令”存在。
> ldd main
returned:
linux-vdso.so.1 (0x00007ffdf4bcc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a10b23000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f7a10f14000)
根据“ldd”命令,没有丢失的共享库
注意: 通过添加这些选项,同一个程序可以在 macosx 上使用 nasm 和 ld 成功编译和链接
-macosx_version_min 11.0 -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem -no_pie
到链接器 ld。
编辑1: 当我删除 ld 的 -lc 以及 asm 文件内的 c 函数调用时,链接程序可以正常工作
编辑2:
readelf -h main
returned:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4005d0
Start of program headers: 64 (bytes into file)
Start of section headers: 19096 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 7
Size of section headers: 64 (bytes)
Number of section headers: 21
Section header string table index: 20
有关该计划的一些额外信息
答案1
感谢这位男士与大家分享他的经历解决方案在这里.多亏了他我才能够解决这个问题。
总而言之,正如@steeldriver 所说,存在一个解释器问题。链接器将我的程序 [/lib/ld64.so.1] 作为 ELF 解释器提供,但此路径根本不存在,我通过以下方式检查了它:
> ls /lib/ld64.so.1
ls: cannot access '/lib/ld64.so.1': No such file or directory
之后,我通过以下方式检查了我的 ubuntu 安装中的解释器路径:
> ls /lib64/ld-*
/lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
因此解决方案是通过以下方式创建其中一个解释器到不存在的解释器路径的链接:
sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1
现在我们再次重新检查不存在的解释器,看看它是否仍然不存在:
> ls /lib/ld64.so.1
/lib/ld64.so.1
现在这个命令返回的是 /lib/ld64.so.1 而不是“不存在的文件”。所以问题解决了,我可以成功运行 ./main