Problems including limits.h with icc-10.1.017 on Linux

[mattst88]

Hi,

I have problems compiling programs that use limits.h such as PHP. The symptoms of this problem appear to differ from person to person and from x86 to x86_64. For instance, I can compile the same version of PHP cleanly with my x86 server, but the compile fails with my Core 2 x86_64 laptop and my Sempron 64 desktop. See this thread for reports.

Commonly, I receive this error:

/usr/include/gentoo-multilib/amd64/limits.h(125): catastrophic error: could not open source file "limits.h"
 # include_next 
                          ^ 

I tried reproducing it with a simple test program, but was unable:

#include 

int main() { return 0; }

[realnc]

Confirmed with GCC 4.3.1 on 64-bit. Always reproducible with the following C++ program:

#include
int main()
{ return 0; }

icpc test.cpp

/usr/include/limits.h(125): catastrophic error: could not open source file
"limits.h"

There is no problem with C.  Only C++.

[TimP]

This doesn't look like a problem with icpc. You are running non-standard C++ ( in place of ) on an unsupported target. icpc tries to use this header the same way as g++, unless something is done behind our backs to break it. Unfortunately, g++ 4.3.1 is somewhat newer than what icpc 10.1 was built to support, so there will undoubtedly be problems elsewhere.

[realnc]

The problem persists even with #include instead of #include (the error message does not change, it still refers to "/usr/include/limits.h").

I know of course that GCC 4.3.1 is too new to be supported. I'm just confirming that there is a problem because I assume ICC makes an effort to be GCC compatible.

The code in /usr/include/limits.h where the error happens:

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

#endif

[mattst88]

This should have been stated earlier, but I experience this with gcc-4.2.x. This isn't a gcc-4.3 issue.

[TimP]

Yes, icpc makes every attempt to search the paths owned by g++, in the same way that the g++ which is active in the same session does. If this problem occurs with icpc, but not with g++, something is wrong with the icpc installation. According to you first post, the include file system in your distro is different from the supported distros.
I'm not expert on it, but this _GCC_LIMITS_H_ scheme appears to be designed to cause the provided by your glibc or other system library installation to be included the first time only, while adding some stuff determined during the fixincludes phase of gcc build. On my linux installation, that system file is /usr/include/limits.h. According to your diagnostic, it may be different on yours.
It's also possible to make a plain limits.h using the Pemberton enquire.c program which used to be provided with gcc, in order to use K&R C to bootstrap in the absence of a system . Maybe you could add that in your project and get something more compatible with generic software. enquire.c should work identically with gcc or icc.

[realnc]

icpc can't find a limits.h even if I compile with:

icpc -I/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include-fixed -I./ -I/opt/intel/cce/10.1.017/include test.cpp

And I created a dummy limits.h in the current directory. icpc simply refuses to pick up a limits.h no matter what.

Using the -no-gcc switch fixes the problem though. But a lot packages won't build with -no-gcc.

Also, compiling with -D_GCC_LIMITS_H_ fixes it too, but I really don't think that's a good idea.

[carlo]

I can confirm that this problem still exists with 10.1.018 (Intel takes 'not supported' very seriously)...

[vermin__willem]

Quoting - realnc

icpc can't find a limits.h even if I compile with:

icpc -I/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include-fixed -I./ -I/opt/intel/cce/10.1.017/include test.cpp

And I created a dummy limits.h in the current directory. icpc simply refuses to pick up a limits.h no matter what.

Using the -no-gcc switch fixes the problem though. But a lot packages won't build with -no-gcc.

Also, compiling with -D_GCC_LIMITS_H_ fixes it too, but I really don't think that's a good idea.

Another, probably better solution:

icc (or icpc) -idirafter/usr/include/linux .....

[KitturGanesh]

Hi,
This issue has been fixed in the 10.1.021 version upwards (based onthe build date that I verified). Could you please download the latest version 10.1.022 and try it out? If the problem still exists, please let me know. Also, the latest 11.0 version 11.0.081 should not have this problem too, just FYI.

The work-around earlier when the problem existed was to use -D_GCC_LIMITS_H_ option. But, it should be fixed in the latest 10.1 version. I tested with that version again on x86_64 EL5 and it worked fine.

-regards,
Kittur

[mattst88]

Hi,

Yes, I just confirmed that 10.1.021 does not have this problem.

Thanks so much!

[NB]

Hi,

Using icc/icpc version 11.0.083 (build 20090318), I don't have any problem.

But I just upgraded to 11.1.046 and now I can't compile my C++ code, I'm having the same issue as posted above. I cannot use "-idirafter /usr/include/linux" or "-D_GCC_LIMITS_H_" in CFLAGs because I need CHAR_BIT which is defined in limits.h...

Anything could be done for that?

Thanx

[JenniferJ]

Quoting - NB

Hi,

Using icc/icpc version 11.0.083 (build 20090318), I don't have any problem.

But I just upgraded to 11.1.046 and now I can't compile my C++ code, I'm having the same issue as posted above. I cannot use "-idirafter /usr/include/linux" or "-D_GCC_LIMITS_H_" in CFLAGs because I need CHAR_BIT which is defined in limits.h...

Anything could be done for that?

Thanx

what is your gcc version? I've tried icpc 11.1.046 with gcc 4.3 and 4.1.2, icpc compiles fine with following src:

#include
int main()
{ return 0; }

[NB]

Quoting - Jennifer Jiang (Intel)

what is your gcc version? I've tried icpc 11.1.046 with gcc 4.3 and 4.1.2, icpc compiles fine with following src:

#include
int main()
{ return 0; }

I am using gcc version 4.4.0 20090630 on ArchLinux. I tried the previous simple example. It works with g++ but not with icpc:
$ icpc test.cpp -o test
/usr/include/limits.h(125): catastrophic error: could not open source file "limits.h"
# include_next
^
compilation aborted for test.cpp (code 4)

I also tried workwaround flags:
$ icpc -no-gcc test.cpp -o test
ld: cannot find -limf
$icpc -idirafter /usr/include/linux test.cpp -o test
ld: cannot find -limf

I would prefer a real solution to a workaround CFLAG. I'll re-verify my installation, but it is simply an upgrade from 11.0...

Thanx a lot.

N

[NB]

After re-packaging / re-installing the compiler, everything works fine. Was probably an error in the installation and not the compiler...