gcc -c无法生成可执行文件需用gcc -o的相关技术疑问

问题背景 #

之前习惯用gcc -c myexecutable mysource.c编译单文件C程序，能生成可执行文件直接运行；但用gcc-9编译某工具时该命令报错gcc: error: myexecutable: No such file or directory。改用gcc -o myexecutable mysource.c可正常生成可执行文件，gcc -c mysource.c仅生成不可执行的mysource.o目标文件。已知-c选项不执行链接操作，此前项目未遇相关问题，现针对以下疑问逐一解答：

1. 哪些场景下编译需要执行链接？ #

• 只要需要生成可执行文件，就必须执行链接操作。链接的核心作用是将编译生成的目标文件（.o）与系统库、第三方库代码合并，补充程序启动的必要入口代码（如系统C库提供的_start函数），最终生成完整的可运行程序。
• 哪怕是单个无外部依赖的源文件，编译出的目标文件仅包含业务代码指令，缺少启动逻辑，必须通过链接整合系统启动代码才能运行。
• 多文件编译场景下，链接负责合并多个目标文件，解决函数、变量的跨文件引用问题。

2. 如何检查源文件是否存在需链接的属性？ #

• 所有C源文件编译为目标文件后，都需要链接才能生成可执行文件，区别仅在于链接时是否需要引入额外外部库：
  • 用nm命令查看目标文件符号表：运行nm mysource.o，若输出中有U开头的符号，代表该符号未定义，需从外部库或其他目标文件引入，链接时需要对应依赖（比如用到printf会显示U printf，需链接C标准库）。
  • 即便没有U开头的符号，单个目标文件也必须链接系统启动代码才能转化为可执行文件。

3. 此前无需链接是巧合还是旧版gcc（如2.95）特性？ #

• 这并非“无需链接”，而是误用命令时的巧合或旧版GCC的容错性行为：
  • -c选项的标准用法是gcc -c 源文件，仅生成目标文件，不接受输出文件名作为前置参数。旧版GCC可能对参数顺序容错性更高，自动忽略无效参数并默认执行了链接，导致你误用命令却得到了预期结果。
  • 新版GCC（如gcc-9）严格遵循参数规范，会将-c后的第一个非选项参数识别为源文件，找不到则报错，因此旧命令失效。

4. 是否应普遍使用-o选项编译？ #

• 是的，推荐始终使用-o选项明确指定输出文件名：
  • 这是符合GCC规范的用法，可避免参数顺序或选项组合导致的意外行为（比如直接用gcc mysource.c会默认生成a.out，用-o可自定义文件名，逻辑更清晰）。
  • 分步骤编译时（先编译为目标文件，再链接），用gcc -c mysource.c生成.o文件，再用gcc -o myexecutable mysource.o完成链接，流程更清晰，也方便多文件项目的编译管理。

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