x86_64架构下C语言手动链接.o文件解决_start缺失问题

你手动调用ld时仅传入了自己编译的a.o和libc.so，缺失了Linux用户态ELF程序启动必需的C运行时（CRT）目标文件集合。
_start是Linux用户态程序的法定入口，这个符号不在你写的业务代码里，也不在libc.so的导出符号中，它由glibc提供的crt1.o目标文件定义，负责完成栈初始化、动态库重定位收尾、全局构造函数调度，最终才会跳转到你实现的main函数，main返回后还会触发exit流程做进程收尾。
除了缺crt1.o导致找不到_start之外，你还缺少配套的CRT桩文件、动态链接器指定配置，就算手动把_start地址写死，程序要么初始化崩溃，要么运行时提示文件不存在——这个"文件不存在"的报错也不是a.out真的丢了，是内核加载ELF时找不到对应路径的动态链接器（ELF解释器）抛出的通用错误。

第一步：确认本机CRT文件路径 #

不同发行版、架构的CRT文件路径不统一，你可以先执行下面的命令快速定位：

# 查glibc提供的crt文件位置
find /usr -name "crt1.o" -o -name "crti.o" -o -name "crtn.o"
# 查gcc自带的配对crt文件位置
find /usr -name "crtbegin.o" -o -name "crtend.o"

64位x86架构的Debian/Ubuntu/Mint（包括你用的MATE桌面版）下，glibc的crt文件一般在/usr/lib/x86_64-linux-gnu/路径下，gcc自带的crtbegin/crtend一般在/usr/lib/gcc/x86_64-linux-gnu/<gcc版本号>/路径下。

第二步：按固定顺序传入链接参数 #

ld对CRT文件的传入顺序有严格要求，顺序错了会报链接错误，完整命令模板如下：

ld \
<你的crt1.o全路径> \
<你的crti.o全路径> \
<你的crtbegin.o全路径> \
a.o \
-dynamic-linker /lib64/ld-linux-x86-64.so.2 \
-lc \
<你的crtend.o全路径> \
<你的crtn.o全路径> \
-o a.out

参数说明：

• 开头三个crt文件负责启动逻辑，其中crt1.o就提供了你要找的_start符号
• -dynamic-linker指定ELF的解释器（动态链接器）路径，64位x86系统固定为/lib64/ld-linux-x86-64.so.2，不加这个参数就会出现你遇到的"运行时提示找不到文件"的问题
• -lc表示链接系统默认路径下的libc.so，不用手动写全libc的绝对路径
• 最后两个crt文件负责启动流程的收尾逻辑，必须放在所有用户目标文件、库文件之后

零错误适配方法 #

如果不想手动找路径，可以随便写个测试C文件，执行带verbose参数的gcc命令查看它的默认链接参数：

gcc -v test.c -o test.out

输出内容里找collect2开头的那一行，这行就是gcc内部调用链接器的完整命令，你把里面的test.o替换成你自己生成的a.o，删掉其他自动生成的临时目标文件参数，直接执行就能得到完全适配你当前系统环境的链接命令，不会出现路径、版本不匹配的问题。

如果你只是想拆分编译流程，不想自己处理复杂的链接参数，完全可以在生成a.o之后，直接调用gcc来做最后一步链接：

# 自行完成预处理、编译、汇编步骤，最后让gcc处理链接逻辑
cpp main.c a.i
cc1 a.i -o a.s
as a.s -o a.o
gcc a.o -o a.out

gcc会自动把所有CRT文件、链接参数按正确顺序传给ld，不会出现入口找不到、运行报错的问题。

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