【问题标题】:Exact meaning of "system headers" for the GCC -MM flagGCC -MM 标志的“系统标头”的确切含义
【发布时间】:2016-02-24 16:26:43
【问题描述】:

根据 GCC 文档,-MM 标志会以这种方式生成依赖:

与 -M 类似,但不提及在系统中找到的头文件 头目录,也不是包含的头文件,直接或 间接地,来自这样的标题。

我刚刚发现,在我的项目中使用 -MM 标志不仅会抑制对系统头文件的依赖,还会抑制对我本地安装在我的主目录中的第三方库头文件的依赖。摆脱系统头文件依赖对我来说通常很方便(因为我不编辑它们),但是我有时会编辑/自定义第三方库,当然我需要在这些编辑之后重新构建我的代码。

那么,我的问题是 GCC 的“系统标头”是什么?假设您在主目录中安装了一个自定义版本的 libpng,并对其进行编辑以满足您的需求……那是 GCC 的“系统头文件”吗?

与此同时,我只是将 -M 作为临时解决方法。

【问题讨论】:

  • 请用一个最小的例子展示如何重现这个问题。它按我的预期工作。

标签: gcc dependencies


【解决方案1】:

系统头目录

在 GCC 中,系统头目录就是这样;系统头目录。确定什么是系统头目录和什么不是系统头目录并不涉及任何魔法。 GCC 将您告诉它的目录视为系统头目录作为系统头目录。

如果您在您的主目录中安装第三方库的头文件,如您的示例中那样,然后继续使用 GCC 编译需要此库的项目,您的编译将由于缺少所述库而失败,否则它将使用库的系统安装版本。这是因为您没有指定您告诉 GCC 包括此本地安装,并且 GCC 不会神奇地为您执行此操作。当您在搜索头文件时指定要包含的目录时,您还告诉 GCC 是否将这些目录视为系统头文件目录。

哪些目录成为系统头文件?

使用命令行选项-iwithprefix-isystem-idirafter 添加的目录被视为系统头目录。所有这三个选项的文档都清楚地表明它们得到了与实际系统头文件相同的特殊处理。此外,环境变量C_INCLUDE_PATHCPLUS_INCLUDE_PATHOBJC_INCLUDE_PATH 中的路径被视为通过-isystem 选项传递,因此也被视为系统标头。

显然,实际的系统头文件,例如编译器附带的或安装到系统中的头文件,当然也被视为系统头文件。

哪些目录没有?

使用-iquote-iwithprefixbefore-I 添加的目录不被视为系统头目录。这还包括来自CPATH 环境变量的目录,它被视为使用-I 选项传递。

执行此操作的源代码在哪里?

由于我花了一些时间搜索 GCC 源代码来查找它是如何定义的,所以我将把这个注释留给任何感兴趣的人:什么是和什么不是系统头的精确定义可以在 @ 中看到gcc/incfile.c 中的 987654333@ 函数。这里,sysp 非零意味着 系统头。在同一个文件中,您还可以找到register_include_chains,它处理从特殊环境变量添加目录。最后,对于选项解析,从 gcc/c-family/c-opts.c 调用 add_path 以添加来自各种选项的目录。

【讨论】:

  • 非常感谢。很详细,提供了我想知道的一切。谢谢!
  • 不客气。我遇到了一个相反的问题,我得到了我不想要的带有-MM 的标题,搜索它并得到一个没有答案的问题。然后决定我不妨挖掘并与其他开发人员分享答案。
猜你喜欢
  • 1970-01-01
  • 2020-06-18
  • 1970-01-01
  • 2021-11-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-09
  • 1970-01-01
相关资源
最近更新 更多