gcc -c source.c 生成 source.o，仅编译汇编不链接；需显式指定-c，多文件须分别处理；构建共享库须加-fPIC；验证用file、nm、readelf。
gcc -c 生成 .o 文件的正确用法
直接运行 gcc -c source.c 就能生成目标文件，输出名默认是 source.o。它只做编译和汇编，跳过链接阶段，所以不会报“undefined reference”这类链接错误，但也不会生成可执行文件。
常见误操作是漏掉 -c，比如写成 gcc source.c —— 这会尝试完整编译+链接，若缺 main 函数或引用未定义符号，就直接失败。
-
-c必须显式指定，没有默认等效行为 - 输出文件名用
-o控制，例如gcc -c main.c -o app.o - 多个源文件要分别加
-c：不能写gcc -c a.c b.c -o out.o（这只会生成a.o，b.c被忽略） - 预处理、编译、汇编三步被压缩在
-c里完成，不生成中间的.i或.s文件
为什么有时生成的 .o 无法被后续链接使用
典型现象是执行 gcc main.o util.o -o prog 时提示 “relocation R_X86_64_32 against symbol ... can not be used when making a shared object”，本质是目标文件缺少位置无关代码（PIC）支持。
这种情况多见于你要把该 .o 用于构建动态库（.so），而非普通可执行文件。
- 普通可执行文件链接：直接
gcc -c xxx.c即可 - 目标是进
.so：必须加-fPIC，即gcc -fPIC -c xxx.c -
-fPIC要在-c阶段就加，链接阶段加无效 - 静态库（
.a）一般不需要-fPIC，但若静态库将来又被用于构建共享库，则也建议加上
多文件项目中怎么批量生成 .o
手动对每个 .c 文件敲一遍 gcc -c 很容易出错，尤其文件名带空格或特殊字符时。推荐用 shell 循环或 Makefile，而不是拼接长命令。
- 简单循环示例：
for f in *.c; do gcc -c "$f" -o "${f%.c}.o"; done - 注意双引号包裹
$f，防止含空格的文件名崩坏 -
${f%.c}是 bash 参数展开，安全去掉后缀，比用sed或basename更轻量 - 如果用了
-I或-D等编译选项，每个gcc -c命令都得带上，不能只在最后链接时加
目标文件生成后怎么确认内容是否正常
光看文件存在、大小非零还不够。真正要验证的是它是否含有效符号、架构匹配、且没被截断。
- 用
file main.o看是否显示 “ELF … object file”，并核对架构（如 x86_64）是否与目标平台一致 - 用
nm -C main.o | head查看符号表，确认有你期望的函数名（未加static的） - 若用
gcc -c时加了-g，可用readelf -wi main.o | head检查调试信息是否嵌入成功 - 不要用
strings main.o判断——目标文件含大量二进制数据，strings会漏关键信息甚至误导
实际项目里，.o 文件只是中间产物，它的生成质量直接影响后续链接能否通过、动态库能否加载、甚至 ASLR 是否生效。最常被忽略的是 PIC 与非 PIC 目标文件混用，以及忘记给所有参与链接的 .o 统一加编译选项（比如都开 -O2 或都关 -fstack-protector）。
