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

发布于 2024-07-22 04:37:34 字数 1050 浏览 18 评论 0原文

当我尝试

$ make depend -f gcc.mak

在我的 Ubuntu 机器上使用中间件时，我得到了

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

This is thecontents around 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

I attempts set

$ 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 包吗？或者是否需要环境变量；也许这可以通过其他方式规避？

原文

When i try to

$ make depend -f gcc.mak

a middleware on my Ubuntu machine I get this

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

This is the contents around 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

I tried setting

$ 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/

(which is where I found another limits.h on my system). I already have libc6-dev installed, could it be that its limits.h has been overwritten by another package? Do I need another -dev package? Or is an environment variable required; perhaps this could be circumvented in some other way?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

轮廓§ 2024-07-29 04:37:34

我在交叉编译时遇到过这个问题。当您执行“make dependent”时，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 的默认路径之前。

I have encountered this problem doing a cross-compile. When you execute a 'make depend' the Makefile will invoke the makedepend program as seen from this assignment:

MAKEDEPPROG=makedepend

makedepend only searches some default include directories starting with /usr/include

Since the #include_next directive means to include the next found instance of the named include file in the search path, this will fail if another one is not found.

For me, the solution was to direct makedepend to search my cross-compiler include directories first. I did this by changing the MAKEDEPPROG assignment to include the -I directive:

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

I suggest reading about the makedepend program (about which I knew nothing before). For example, it was not obvious to me that makedepend would not use an environment search path. The -I directive puts the specified search path before makedepend's default paths.

回复收藏 0 原文