刚写完一段网络通信的 C 代码，make 一下，报错：'undefined reference to `inet_pton`'。翻遍源码，函数明明写了，头文件也 #include 了，咋还找不到？别急着怀疑编译器坏了——八成是编译选项没配对。
链接时找不到函数？先看 -l 跟没跟上
比如用到了 libpcap 抓包，写了 #include <pcap.h>，但忘了加 -lpcap：
gcc sniffer.c -o sniffer # ❌ 缺少 -lpcap结果就是 'undefined reference to `pcap_open_live`'。正确写法得带上库名：
gcc sniffer.c -lpcap -o sniffer # ✅同理，用 getaddrinfo 或 inet_pton 时，Linux 下得显式加 -lnsl（老系统）或 -lresolv（部分场景），新 glibc 有时能自动推，但别赌运气。
架构不匹配：32 位代码硬塞进 64 位环境
在 64 位 Ubuntu 上编译一个旧的网络工具，加了 -m32 却没装 multilib：
gcc -m32 client.c -o client立马报错：fatal error: bits/libc-header-start.h: No such file or directory。这不是代码问题，是系统缺 32 位头文件和库。得先装：sudo apt install gcc-multilib libc6-dev-i386。
优化等级太高，调试信息全丢光
加了 -O3 编译后，gdb 调试时变量显示 <optimized out>，断点跳来跳去，抓不到 socket 连接失败的真实 errno。这不是 bug，是编译器把中间变量全优化没了。开发阶段建议用 -O0 -g，等调通了再升优化级。
忽略警告，等于埋雷
比如用了过时的 inet_aton()，编译时 warning 提示 'deprecated'，你按回车跳过，结果在某些嵌入式设备上一运行就段错误——因为目标平台的 libc 根本没实现这个符号。加上 -Werror 让警告变错误，反而能提前暴露兼容性问题。
编译选项不是越长越高级，而是要跟代码用途、目标平台、调试阶段严丝合缝。改一行 Makefile，可能比查两小时 core dump 更快解决问题。