gcc - 为什么我不能明确 `-I/usr/include` ?

标签 gcc include clang

当通过 -I 显式包含时,gcc 和 clang 似乎都会从包含目录列表中默默地丢弃 /usr/include。 是否有特定原因说明为什么普通编译器显然不允许包含系统的 include 目录?


背景:

假设您依赖于位于 /usr/include 中的头文件,同时通过 CPATH 从您的构建系统继承了一个包含同一头文件的不兼容版本的目录环境变量(将该目录有效地附加到右侧的 -I 列表中)。

最佳答案

GCC 忽略 -I/usr/include 因为它默认是系统头目录,使用 -I 会把它变成非系统头,导致令人困惑的行为,特别是对于不完全符合语言标准的系统头文件。 (例如,GCC 为系统 header 提供了更大的自由度并抑制了警告。)

如果您使用-isystem/usr/include,那么/usr/include 会移动到搜索列表的前面。但是,您可能还必须移动其他默认搜索路径条目,以避免破坏太多东西。 gcc -v 将打印整个搜索路径。

关于gcc - 为什么我不能明确 `-I/usr/include` ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53437754/

相关文章:

templates - 使用声明引用到 C,它是 D 的基类(别名),但它不被识别为有效

c++ - 是否有像包含目录别名这样的概念?

c++ - 构建 clang 示例时出现 fatal error : 'type_traits' file not found #include <type_traits>,

c++ - 是否有关于 std::move 的这种使用的编译警告?

c - 如何判断程序是在 x86/x64 还是 ARM Linux 平台上运行

c++ - 至强的 gcc 优化标志?

linux - undefined symbol : _gst_fraction_type for gstreamer 1. *

c - 为什么要定义函数而不是包含文件

c++ - 检查 main() 中未使用的头文件

warnings - 避免 block 中的 "expression result unused"警告