当通过/usr/include显式包含时，gcc和clang似乎都默默地从包含目录列表中丢弃了CPATH。
为什么普通的编译器显然不允许其包含系统的include目录，是否有特定原因？
背景：
假设您依靠-I中的头文件，而通过public class HexHelper
{
public static string GetUTCFileTimeAsHexString()
{
string sHEX = "";
long ftLong = DateTime.Now.ToFileTimeUtc();
int ftHigh = (int)(ftLong >> 32);
int ftLow = (int)ftLong;
sHEX = ftHigh.ToString("X") + ":" + ftLow.ToString("X");
return sHEX;
}
}
环境变量从构建系统继承了包含同一头文件不兼容版本的目录（有效地将该目录追加到$HH = @"
public class HexHelper
{
public static string GetUTCFileTimeAsHexString()
{
string sHEX = "";
long ftLong = DateTime.Now.ToFileTimeUtc();
int ftHigh = (int)(ftLong >> 32);
int ftLow = (int)ftLong;
sHEX = ftHigh.ToString("X") + ":" + ftLow.ToString("X");
return sHEX;
}
}
"@;
Add-Type -TypeDefinition $HH;
$HexString = [HexHelper]::GetUTCFileTimeAsHexString();
$HexString;
从右边的列表中。）
答案 0 :(得分：1)
GCC会忽略-I/usr/include，因为默认情况下它是系统头目录，并且使用-I会将其转换为非系统头，从而导致混乱的行为，尤其是对于未完全对齐的系统头语言标准。 （例如，GCC为系统标头提供了更大的自由度并禁止显示警告。）
如果使用-isystem /usr/include，则/usr/include移到搜索列表的最前面。但是，您可能还必须移动其他默认搜索路径条目，以免破坏太多内容。 gcc -v将打印整个搜索路径。