为何GCC优先使用头文件搜索路径靠后的stdio.h？

错误日志 #

LD_LIBRARY_PATH=.:/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/lib "gcc-12 -M -o conftest -I/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/include/ruby-3.1.0/x86_64-linux -I/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/include/ruby-3.1.0/ruby/backward -I/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/include/ruby-3.1.0 -I. -I/opt/local/include -I/usr/local/include -I/opt/homebrew/include -I/usr/include -I/home/linuxbrew/.linuxbrew/opt/libyaml/include -I/home/linuxbrew/.linuxbrew/opt/openssl@3/include -I/home/linuxbrew/.linuxbrew/opt/readline/include   -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wundef  -fPIC conftest.c  -L. -L/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/lib -L/opt/local/lib -Wl,-rpath,/opt/local/lib -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/opt/homebrew/lib -Wl,-rpath,/opt/homebrew/lib -L/usr/lib -Wl,-rpath,/usr/lib -L/home/linuxbrew/.linuxbrew/opt/libyaml/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/libyaml/lib -L/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -L/home/linuxbrew/.linuxbrew/opt/readline/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/readline/lib -L. -fstack-protector-strong -L/home/linuxbrew/.linuxbrew/opt/libyaml/lib  -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/libyaml/lib -L/home/linuxbrew/.linuxbrew/opt/openssl@3/lib  -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -L/home/linuxbrew/.linuxbrew/opt/readline/lib  -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/readline/lib -rdynamic -Wl,-export-dynamic -Wl,--no-as-needed     -Wl,-rpath,/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/lib -L/home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/lib -lruby  -lm  -lc"
In file included from /home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/include/ruby-3.1.0/ruby/defines.h:16,
                 from /home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/include/ruby-3.1.0/ruby/ruby.h:25,
                 from /home/linuxbrew/.linuxbrew/Cellar/ruby@3.1/3.1.3_1/include/ruby-3.1.0/ruby.h:38,
                 from conftest.c:1:
/usr/include/stdio.h:781:10: fatal error: bits/sys_errlist.h: No such file or directory
  781 | #include <bits/sys_errlist.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
checked program was:
/* begin */
1: #include "ruby.h"
2: 
3: int main(int argc, char **argv)
4: {
5:   return !!argv[argc];
6: }
/* end */

核心疑问 #

编译参数的-I选项中，-I/opt/homebrew/include排在-I/usr/include之前，且前者目录下存在stdio.h，该文件并未包含#include <bits/sys_errlist.h>。按照GCC文档，编译器应优先使用路径靠前的头文件，但实际编译时却加载了/usr/include下的stdio.h，导致出现找不到头文件的错误。

环境信息 #

• WSL 1.0.3.0
• Ubuntu 20.04
• Homebrew GCC 12.2.0
• Homebrew Ruby 3.1.3

原因分析 #

1. 路径无效/架构不兼容：/opt/homebrew是macOS Homebrew的默认路径，WSL Ubuntu环境下该目录要么不存在，要么存放的是ARM架构（Apple Silicon）的头文件，与WSL的x86_64架构不兼容，GCC会自动跳过这个无效路径，转而使用系统默认的/usr/include。
2. GCC内置搜索逻辑：Homebrew编译的GCC可能默认优先搜索系统标准库路径，当指定的-I路径无法提供可用头文件时，会 fallback 到系统路径。

解决方法 #

• 移除无效路径：直接删除编译参数中的-I/opt/homebrew/include，通过环境变量重置编译路径后重新执行gem编译：

  export CPPFLAGS="-I/home/linuxbrew/.linuxbrew/opt/libyaml/include -I/home/linuxbrew/.linuxbrew/opt/openssl@3/include -I/home/linuxbrew/.linuxbrew/opt/readline/include"
  export LDFLAGS="-L/home/linuxbrew/.linuxbrew/opt/libyaml/lib -L/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -L/home/linuxbrew/.linuxbrew/opt/readline/lib"
  

• 修复系统依赖（备选）：如果需要使用系统库，安装Ubuntu标准库开发包补全缺失的头文件：

  sudo apt-get install libc6-dev
  

内容的提问来源于stack exchange，提问作者Alexey Romanov