12
votes

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?

6
This should work as it is. What do you see when you add '-v' to your compilation command? - Laurynas Biveinis
I'm guessing that limits.h is missing (or overwritten). -v gets me GNU Make 3.81 Target: x86_64-linux-gnu gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) - Jonas Byström
The another limits.h that you can find is the one which should be pulled in by include_next. Can you add -v to the gcc command line that does the failing compilation, i.e. gcc -v -c foo.c ? The interesting part in its output would be #include <...> search starts here: /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 End of search list. - Laurynas Biveinis
you may want to try export CPATH=$(env | grep _INC | cut -d= -f2 | paste -d: -s) and export LIBRARY_PATH=$(env | grep _LIB | cut -d= -f2 | paste -d: -s) - George

6 Answers

3
votes

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.

2
votes

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.

1
votes

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).

0
votes

the package that you need is glibc.

0
votes

Consider using #include_next <limits.h> (gcc extension) in order to force gcc to look at the next found limits.h in the include path (which should be the toolset's copy).

-1
votes

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.