使用-nostdlib后报undefined reference to 'main'，是因为它禁用了crt0.o等启动文件和libc，导致_start符号缺失；此时必须手动提供_start并用-e _start指定入口点，或改用-nodefaultlibs保留启动文件。
使用 -nostdlib 后程序连 main 都找不到
加了 -nostdlib，编译可能通过，但链接阶段直接报错：undefined reference to 'main' 或更诡异的 undefined reference to '_start'。这不是代码写错了，而是 GCC 默认帮你链接的启动代码（crt0.o 等）被彻底禁用了。
标准 C 程序启动流程是：操作系统调用 _start → _start 初始化栈/寄存器 → 调用 __libc_start_main → 最终跳转到你写的 main。而 -nostdlib 会同时屏蔽 libc 启动文件（crt*.o）和标准库（libc.a/libc.so），_start 符号就没了。
- 若你确实要写裸机程序或最小二进制，必须自己提供
_start符号，并用-e _start显式指定入口点 - 想保留
main但去掉 libc？不行——main依赖__libc_start_main，而它在 libc 中 - 误加
-nostdlib又想快速恢复？删掉它，或改用更温和的-nodefaultlibs（保留启动文件，只去掉 libc）
-nostdlib 和 -nodefaultlibs 的关键区别
这两个参数常被混用，但行为完全不同：
-
-nostdlib：完全跳过所有默认路径下的启动文件（crt0.o、crti.o、crtn.o）和标准库（libc、libm、libgcc） -
-nodefaultlibs：只跳过标准库（libc.a/libc.so 等），但保留 crt*.o 启动文件，所以main仍能正常进入
典型场景：你要链接自己的 libmycore.a 并避免 libc 干扰，但又不想手写 _start —— 就该用 -nodefaultlibs，而不是 -nostdlib。
验证方式：编译后用 readelf -l a.out | grep interpreter，带 -nostdlib 的输出里通常没有 INTERP 段（即不依赖动态链接器），而 -nodefaultlibs 的仍有。
为什么 -nostdlib 下 printf 这类函数直接失效
不是“找不到定义”，而是根本没机会定义——printf 在 libc 中，而 -nostdlib 连 libc 的 .a/.so 都不搜，更不会把 libc.a 里的目标文件拉进来。
- 即使你手动加
-lc，也会失败：因为-nostdlib已禁止查找默认库路径，-lc找不到libc.a - 真要调用
printf，得显式指定路径：-L/usr/lib -lc，但这违背了-nostdlib的初衷 - 常见替代方案：用系统调用（如
write(1, ...)）代替 libc 函数，此时只需链接libgcc（用-lgcc）处理底层运算
嵌入式或 Bootloader 场景下用 -nostdlib 的硬性要求
在写 bootloader、内核模块或 freestanding 环境时，-nostdlib 是必须的，但配套动作缺一不可：
- 必须提供自己的
_start汇编入口（通常放在单独的start.s文件中） - 需显式链接
libgcc（-lgcc）来支持除法、浮点等硬件不直接支持的操作 - 链接脚本（
-T linker.ld）必须明确定义内存布局和段位置，不能依赖默认脚本 - 禁用所有依赖 libc 的编译选项，例如
-fno-builtin（否则编译器可能悄悄插入memcpy等调用）
漏掉任意一项，都可能表现为程序加载后立即崩溃，或跑飞——而且这种问题往往没有明确错误提示，只能靠 objdump 和调试器逐条看指令。
