自行编译的GCC 12如何识别使用自身C++头文件而非系统头文件

• 你观察到的现象完全来自GCC编译时内置的路径硬编码逻辑，和环境变量、系统配置没有关系：从源码构建GCC时，configure步骤传入的--prefix安装前缀，会被写入最终生成的g++二进制的内置搜索规则中，且这套规则是相对于g++可执行文件自身的位置做相对路径解析，不是写死的绝对路径。这就是你把整个GCC12安装目录移动到其他位置后，它依然能准确找到自带头文件的根本原因。
• g处理C标准头文件搜索时，优先级最高的就是自身内置的版本专属路径，以你编译的GCC 12.1.0为例，它会优先查找自身安装目录层级下的include/c++/12.1.0/、include/c++/12.1.0/x86_64-pc-linux-gnu/这类自带路径，遍历完所有内置专属路径后，才会继续搜索系统级的/usr/include/c++/9/、/usr/include等公共路径。系统自带的GCC 9.4.0的g二进制，内置的安装前缀是/usr，所以它自然会优先加载/usr/include/c++/9/下的头文件，两个版本的g搜索逻辑完全独立，互不干扰。
• 你遇到的「头文件用了GCC12版本、链接的libstdc++.so.6却是系统版本」的不匹配问题，是因为动态库的默认搜索规则和头文件不一样：除非你构建GCC时开启了--enable-default-rpath配置选项，或者编译测试程序时手动传入-Wl,-rpath=/path/to/gcc12/lib64参数指定运行时库搜索路径，否则动态链接器不会主动去GCC的自安装目录下找libstdc++.so.6，只会按系统默认规则加载/usr/lib下的老版本库，这也是你需要手动用LD_PRELOAD预加载新版本库的原因。

你可以直接执行以下命令，查看自己编译的g++的完整头文件搜索优先级列表，验证上述逻辑：

/path_to_gcc12_bin/g++ -v -E -x c++ - < /dev/null

输出内容中#include <...> search starts here:段落下方的路径，就是按搜索优先级从高到低排列的所有头文件目录，排在最前面的就是GCC12自带的12.1.0版本头文件路径。

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