GCC构建问题（#include_next limits.h）

Question

当我在我的Ubuntu机器上尝试构建中间件时，我运行以下命令：

$ make depend -f gcc.mak

我得到了以下错误信息：

/usr/include/../include/limits.h:125:26: 错误：无法搜索limits.h文件的包含路径

这是与limits.h: 125相关的内容：

/* Get the compiler's limits.h, which defines almost all the ISO constants.
We put this #include_next outside the double inclusion check because
    it should be possible to include this file more than once and still get
    the definitions from gcc's header.  */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
/* `_GCC_LIMITS_H_' is what GCC's file defines.  */
# include_next <limits.h>
#endif

我尝试设置以下环境变量：

$ export INCLUDE=/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed/
$ export C_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed/
$ export CPLUS_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed/

(那里我在系统上找到了另一个limits.h)。我已经安装了libc6-dev，可能它的limits.h已被另一个软件包覆盖了吗？我需要另一个-dev软件包吗？或者需要环境变量吗？也许可以用其他方法绕过这个问题？

- Jonas Byström

---

这应该可以直接运行。当您在编译命令中添加“-v”时，您看到了什么？ - Laurynas Biveinis

我猜测limits.h文件丢失或被覆盖了。-v可以让我看到GNU Make 3.81版本，目标是x86_64-linux-gnu，gcc版本为4.3.3（Ubuntu 4.3.3-5ubuntu4）。 - Jonas Byström

你可以找到另一个limits.h，它应该由include_next引入。你能在失败的编译命令行中添加-v吗？例如gcc -v -c foo.c？其输出中有趣的部分将是： #include <...>搜索从这里开始: /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fixed /usr/include 搜索列表结束。 - Laurynas Biveinis

你可以尝试使用以下命令：export CPATH=$(env | grep _INC | cut -d= -f2 | paste -d: -s) 和 export LIBRARY_PATH=$(env | grep _LIB | cut -d= -f2 | paste -d: -s)。 - George

Answer 1

我在进行交叉编译时遇到了这个问题。当你执行'make depend'命令时，Makefile将调用makedepend程序，如下面的分配所示：

MAKEDEPPROG=makedepend

makedepend 只搜索一些默认的包含目录，从 /usr/include 开始

由于 #include_next 指令表示在搜索路径中包含命名的包含文件的下一个找到的实例，如果未找到另一个实例，则会失败。

对我来说，解决方案是让 makedepend 首先搜索我的交叉编译器包含目录。我通过更改 MAKEDEPPROG 分配以包括 -I 指令来实现这一点：

MAKEDEPPROG=makedepend -I < path/to/cross-compiler/include-fixed >

我建议了解一下makedepend程序（之前我对它一无所知）。例如，我以前不知道makedepend不会使用环境搜索路径。 -I指令将指定的搜索路径放在makedepend默认路径之前。

- JSAnderson

---

我应该把它放在哪里？ - Rafael Lima

Answer 2

我曾经遇到使用STLport 5.1.5编译时的问题，但是看起来在STLport 5.2.0中已经修复了这个问题。该问题在STLport 发布说明中有记录。在获取了STLport 5.2.1的副本后，编译成功且没有任何问题。

- sudar

Answer 3

这很可能是这个问题：https://jira.apache.org/jira/browse/STDCXX-768。 我的解决方法是添加编译器选项-I/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed (该路径包含limits.h)。

- Alexander Samoylov

Answer 4

你需要的软件包是 glibc。

- ferdna

---

听起来没问题。我会把它标记为解决方案，即使我没有验证过它。 - Jonas Byström

我正在尝试为Android编译（因此没有glibc），我也遇到了这个错误。找不出应该包括哪个标头文件。 - Wyatt Ward

Answer 5

考虑使用#include_next <limits.h>（gcc扩展）来强制gcc查找包含路径中下一个找到的limits.h文件（应该是工具集的副本）。

- ASk

---

我没有其他（合理的）limits.h。我需要GCC limits.h。include-fixed中的那个似乎不太对。 - Jonas Byström

Answer 6

我不太记得具体的分辨率了，但它与某些缺失的软件包有关。在使用apt-get获取了更多的内容后，它对我起作用了。

- Jonas Byström

---

最好不说任何话。 - Rafael Lima

@RafaelLima：对于某些人可能是这样，但对我来说，发现我缺少软件包比认为我的系统存在配置问题更有用。 - Jonas Byström