I know bugs about version bumps should usually wait a week or so, but since icc wasn't bumped to 10.1.015, I figured I'd go ahead and give a heads-up about 10.1.017. The reason this is important is that it allows programs to compile that otherwise failed with the error about including limits.h, for instance php. Reproducible: Always Steps to Reproduce:
Finally bumped. Thanks.
(In reply to comment #0) > The reason this is important is that it allows programs to compile that > otherwise failed with the error about including limits.h, for instance php. I still get that error with GCC 4.3.1.
(In reply to comment #2) > (In reply to comment #0) > > The reason this is important is that it allows programs to compile that > > otherwise failed with the error about including limits.h, for instance php. > > I still get that error with GCC 4.3.1. There are many programs which failed to build with gcc-4.3, and many were fixed already. If you encounter more, could you please file new bugs to help us track them down? Thanks.
(In reply to comment #3) > (In reply to comment #2) > > > > I still get that error with GCC 4.3.1. > > There are many programs which failed to build with gcc-4.3, and many were > fixed already. If you encounter more, could you please file new bugs to help > us track them down? (Sorry for the late reply; I thought I had added myself to CC, but actually I didn't :P) I get that error with *all* C++ programs that include "limits.h". This won't compile: #include "limits.h" int main() { return 0; } /usr/include/limits.h(125): catastrophic error: could not open source file "limits.h" So I guess the list of affected programs would be both endless as well as pointless. In any event, the bug is still there in icc-10.1.017, at least on AMD64 with gcc-4.3.1-r1.
> I get that error with *all* C++ programs that include "limits.h". This won't > compile: > > #include "limits.h" > int main() { return 0; } > > /usr/include/limits.h(125): catastrophic error: could not open source file > "limits.h" Hmm, indeed this is quite severe. I get this on amd64 multilib with gcc-4.3.1-r1, but not with other gcc versions. Did you try to contact upstream about it? icc and gcc have had some compatibility problems with the 10.1 versions and gcc >= 4.2. Thanks for tracking this down.
(In reply to comment #5) > Hmm, indeed this is quite severe. I get this on amd64 multilib with > gcc-4.3.1-r1, but not with other gcc versions. I never got the hang the whole multilib thing :P I don't know if I'm on multilib or not. I have lib32 and lib64 (and run 32-bit binaries just fine), though I'm not sure if that implies I'm on multilib. > Did you try to contact upstream > about it? icc and gcc have had some compatibility problems with the 10.1 > versions and gcc >= 4.2. > Thanks for tracking this down. Someone informed upstream and I confirmed: http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30259786.aspx However, Intel doesn't seem very interested in anything that doesn't have "RedHat" or "Novell" in it's name. The only comment of an Intel employee I could find about Gentoo is "We've not tried gentoo around here, goanuj, and probably won't any time soon." :P
