gcc -c 仅生成目标文件（.o），不进行链接；它停在汇编后阶段，适用于多文件分步编译、避免重复构建及符号调试，但需后续显式链接才能生成可执行文件。
gcc -c 只生成 .o 文件，不链接
-c 的核心作用就是让 GCC 停在「汇编完成」这一步，只输出目标文件（.o），跳过链接阶段。它不是“编译失败”，而是明确告诉编译器：“别管 main 函数找不找得到、库有没有链接上，我只要机器码片段”。
- 常见错误现象：执行
gcc -c main.c后没报错，但也没生成可执行文件——这是正常行为，不是漏写了-o - 典型使用场景：多源文件项目中，先分别编译
utils.c、main.c为utils.o、main.o，再统一链接：gcc main.o utils.o -o app - 参数差异：
-c不接受输入多个源文件时指定单个-o输出名（比如gcc -c a.c b.c -o out.o会报错），必须每个源文件单独配一个-o，或依赖默认命名（a.c → a.o） - 性能影响：对大型项目，
-c配合make能避免重复编译未改动的模块；但若误用（比如忘了后续链接），会导致运行时找不到./app
不加 -c 时，GCC 默认会尝试链接
当你只写 gcc main.c，GCC 会走完预处理→编译→汇编→链接四步。一旦代码里调用了 printf 却没连 -lc，或者用了 sqrt 却没加 -lm，就会在最后一步报类似 undefined reference to 'sqrt' 的链接错误——而 -c 能帮你提前避开这类干扰，专注验证单个模块的语法和逻辑。
- 容易踩的坑：在头文件里声明了函数，但实现放在另一个
.c文件里，此时直接gcc -c main.c不会报错（因为不检查实现是否存在）；但若漏掉对应.o进最终链接，运行时才会暴露问题 - 调试价值：配合
nm main.o可查看符号表，确认函数是否被正确编译进目标文件，比直接跑可执行文件更轻量 - 注意兼容性：
-c输出的.o格式依赖当前平台（如 x86_64 和 aarch64 的.o不能混用），交叉编译时必须用对应工具链的gcc -c
和 -S、-E 的关键区别在哪
-c 输出的是二进制目标文件（.o），而 -S 输出人类可读的汇编文本（.s），-E 输出宏展开后的 C 代码（.i）。三者都是“中途停步”，但产物层级不同：
-
-E main.c -o main.i：适合查#define是否按预期展开、#include路径是否正确 -
-S main.c -o main.s：适合观察编译器是否把循环优化成了向量化指令 -
-c main.c -o main.o：适合构建流程、做静态分析、或打包进静态库（ar rcs lib.a main.o） - 混淆风险：有人误以为
gcc -c main.c是“编译失败”，其实是成功生成了main.o，只是 ls 时没注意这个文件
-c 看似简单，但它的边界很清晰——它不管符号能不能解析、也不管启动代码怎么放。真正麻烦的永远是后续那步链接：符号缺失、库顺序错、ABI 不匹配……这些都不会在 -c 阶段暴露。 
