gcc -v 输出中真正有用的是 COLLECT_GCC_OPTIONS、cc1 启动命令、as 和 collect2 调用三类行；重定向日志必须用 2>&1 才能捕获 stderr 错误；configure/make 构建错误需查 config.log 和 make V=1；-Wbuiltin-declaration-mismatch 警告提示内置函数名冲突，需修改自定义声明。
gcc -v 输出里哪些行真正有用
直接看 gcc -v 的完整输出容易被淹没在一堆路径和参数里。真正该盯住的是三类行：COLLECT_GCC_OPTIONS（实际生效的编译选项）、cc1 启动命令（预处理+编译阶段）、as 和 collect2 调用（汇编和链接阶段）。如果链接失败，collect2 后面跟的错误（比如 undefined reference to 'xxx'）就是根源。
重定向日志时为什么必须写 2>&1
gcc 把错误信息（如语法错误、未定义符号）输出到 stderr，而普通提示（如“writing output file”）走 stdout。只用 > compile.log 会漏掉所有报错。必须加 2>&1 把 stderr 合并进 stdout，否则日志里看不到关键错误。
-
gcc -o a.out main.c > log.txt 2>&1—— 正确，全部进文件 -
gcc -o a.out main.c 2> log.txt—— 错误，stdout（比如成功提示）还在终端，stderr 单独进文件，信息割裂 - 用
tee时也一样：gcc ... | tee log.txt默认不捕获 stderr，得写成gcc ... 2>&1 | tee log.txt
configure/make 构建时怎么拿到真实错误
很多项目用 autotools 或 cmake，表面报错在 make 阶段，但真正问题常藏在 ./configure 检查里。比如 configure 没检测到 libssl，后面 make 就会报 openssl/ssl.h: No such file or directory。这时要先看 config.log，搜索 checking for openssl 或 configure: error 行；再运行 make V=1（而非默认静默模式），才能看到实际执行的 gcc 命令和参数。
警告当错误用：-Wbuiltin-declaration-mismatch 是什么信号
像 built-in function ‘index’ declared as non-function [-Wbuiltin-declaration-mismatch] 这类警告，本质是编译器在提醒你：代码里有个叫 index 的变量或函数声明，撞上了 GCC 内置函数名。它不会导致编译失败，但后续调用 index() 时行为可能异常——比如你本意是调标准库函数，结果却调到了自己定义的同名变量。解决方式只有两个：grep -r "int index" . 找出冲突定义，改成 idx 或 index_pos；或者确认真要用内置函数，就删掉自定义声明，并确保 #include 在前。
最常被忽略的是：警告本身不中断编译，但上线后可能因符号解析顺序不同引发诡异 crash。别跳过带 -W 的输出，尤其涉及内置函数、类型转换、未初始化变量的警告。
