C++ GCC 构建问题（#include_next limits.h）
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/871952/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
GCC build problem (#include_next limits.h)
提问by Jonas Bystr?m
When i try to
当我尝试
$ make depend -f gcc.mak
a middleware on my Ubuntu machine I get this
我的 Ubuntu 机器上的中间件我得到了这个
/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:
这是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?
（这是我在我的系统上发现另一个limits.h 的地方）。我已经安装了 libc6-dev，是不是它的 limits.h 已经被另一个包覆盖了？我需要另一个 -dev 包吗？或者是否需要环境变量；也许这可以通过其他方式规避？
采纳答案by Jonas Bystr?m
the package that you need is glibc.
您需要的软件包是 glibc。
回答by sudar
I had faced my problem with compiling with STLport 5.1.5, but looks like the issue is fixed is STLport 5.2.0. The issue is documented in STLport Release Notes. After getting a copy of STLport 5.2.1, the compilation went successfully without hiccups.
我在使用 STLport 5.1.5 进行编译时遇到了问题，但看起来问题已解决是 STLport 5.2.0。该问题记录在 STLport发行说明中。拿到 STLport 5.2.1 的副本后，编译成功，没有出现任何问题。
回答by JSAnderson
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:
我在做交叉编译时遇到了这个问题。当您执行“make Depend”时，Makefile 将调用 makedepend 程序，如下作业所示：
MAKEDEPPROG=makedepend
makedepend only searches some default include directories starting with /usr/include
makedepend 只搜索一些以开头的默认包含目录 /usr/include
Since the #include_nextdirective 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.
由于该#include_next指令意味着在搜索路径中包含下一个找到的命名包含文件的实例，如果找不到另一个实例，这将失败。
For me, the solution was to direct makedepend to search my cross-compiler include directories first. I did this by changing the MAKEDEPPROGassignment to include the -Idirective:
对我来说，解决方案是让 makedepend 首先搜索我的交叉编译器包含目录。我通过更改MAKEDEPPROG分配以包含-I指令来做到这一点：
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 -Idirective puts the specified search path before makedepend's default paths.
我建议阅读 makedepend 程序（我之前对此一无所知）。例如，makedepend 不使用环境搜索路径对我来说并不明显。该-I指令将指定的搜索路径放在 makedepend 的默认路径之前。
回答by Alexander Samoylov
This is most likely this issue: https://jira.apache.org/jira/browse/STDCXX-768. The workaround for me was to add the compiler option -I/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed (this path contains limits.h).
这很可能是这个问题：https: //jira.apache.org/jira/browse/STDCXX-768。我的解决方法是添加编译器选项 -I/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed（此路径包含limits.h）。
回答by ASk
Consider using #include_next <limits.h>(gcc extension) in order to force gcc to look at the next found limits.hin the include path (which should be the toolset's copy).
考虑使用#include_next <limits.h>(gcc extension) 以强制 gcc 查看limits.h包含路径中的下一个（应该是工具集的副本）。
回答by Jonas Bystr?m
I don't exactly remember the resolution any more, but it had to do with some missing package. After apt-getting some more stuff, it worked for me.
我已经不记得分辨率了，但它与一些丢失的包有关。在获得更多东西之后，它对我有用。
