关于c ++：GCC构建问题(＃include_nextlimits.h)


GCC build problem (#include_next limits.h)

当我尝试

1
$ make depend -f gcc.mak

我的Ubuntu机器上的中间件我明白了

1
/usr/include/../include/limits.h:125:26: error: no include path in which to search for limits.h

这是关于limits.h：125的内容：

1
2
3
4
5
6
7
8
9
/* 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

我尝试设置

1
2
3
$ 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/

(这是我在系统上找到另一个limit.h的地方)。 我已经安装了libc6-dev，可能是它的limits.h被另一个软件包覆盖了吗？ 我需要另一个-dev软件包吗？ 还是需要环境变量？ 也许可以通过其他方式来规避？

相关讨论

我在交叉编译时遇到了这个问题。执行" makedepend"时，Makefile将调用makedepend程序，如从此分配中看到的：

1
MAKEDEPPROG=makedepend

makedepend仅搜索以/usr/include开头的一些默认包含目录

由于#include_next指令意味着在搜索路径中包括命名的包含文件的下一个找到的实例，因此如果找不到另一个实例，则该实例将失败。

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

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

我建议阅读有关makedepend程序的信息(对此我以前一无所知)。例如，对我而言，makedepend不会使用环境搜索路径并不明显。 -I指令将指定的搜索路径放在makedepend的默认路径之前。

相关讨论

我在使用STLport 5.1.5进行编译时遇到了问题，但看起来该问题已解决，是STLport 5.2.0。 STLport发行说明中记录了该问题。获得STLport 5.2.1的副本后，编译顺利进行，没有出现任何问题。

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

考虑使用#include_next (gcc扩展名)，以强制gcc查看包含路径(应该是工具集的副本)中下一个找到的limits.h。

相关讨论

您需要的软件包是glibc。

相关讨论

我完全不记得分辨率了，但是它与缺少的程序包有关。在获得更多东西之后，它对我有用。

相关讨论