Under Windows 7, with Intel C++ Composer XE 2013 SP1 update 2 version. under Visual Studio 2008.
In most of the projects the compiler found <stdint.h> , but in a few I got the following error :
1>------ Build started: Project: CatShell, Configuration: Release Win32 ------
1>Compiling resources... (Microsoft VC++ Environment)
1>Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>..\..\..\sdlCAT3D\rad.h(11) : fatal error RC1015: cannot open include file 'stdint.h'.
1>Build log was saved at "file://C:\ALA71213\CatShell\CatShell\CatShell\Release\BuildLog.htm"
1>CatShell - 1 error(s), 0 warning(s), 0 remark(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
The project shoud be using ICL . In these case I only copy the original project from (without problem) from a path to other path.
Are you building an open source project? I'd like to reproduce the error that your'e seeing in-house so I can see what's going on. It might also be worth trying to build it with the latest version of the compiler which is update 3 I believe (you said you were using update 2). --Melanie
Dear Melanie. It is not an open source, and it is part of a big project with several dependances. Looks like the error comes from a parsing inside MS VC 2008, before ICL takes the job. But the project is configured for Intel ( we never compile with MS VC, the project needs C99).
The funny thing is that I only copy a whole directory structure from a branch called \ALA712\ to a new branch called \ALA71213\ , for version control. There is not problem with absolute path, the only problem is with stdint.h, written as :
And, this is not the first time that I found the problem, but I let it pass without further analysis.
If I put the absolute path to stdint.h, inside Intel include path, I got an error message reporting the invalid use of "include_next" (see a portion of stdint.h, with include_next). T
he project setup is for ICL and with C99 support.
#elif _MSC_VER >= 1600 /* VS2010 */
** MSVS 2010 supports stdint.h, so we use MS header.
Regarding the use of last update, I am forced to say that we are affraid of new bug in each update !! Sorry for being so crude. Several times I reported bugs that appeared in "updates". The last one forced us to change several source for a wrong initialization in OpenMP loops. I asked and it is not solved in update 3, so why to take the risk ? I prefer to wait a long time and see the comment from other users. (we develop for radiotherapy and neurosurgery).
Thanks . Armando.
I found a solution to the problem, but something is wrong with the integration between VS enviroment and ICL, any way.
If the include of stdint.h is conditional for use only with ICL :
the problem is gone ! If I remove the check for __INTEL_COMPILER, MS-VC 2008 starts a parsing (do not know why ??) and aborts compilation with a fatal error at the very begining.
Dear Prince, I guess you are right ! But I do not use VS, I only am forced to use parts VS because Intel C/C++ is not a true stand alone system, I confess that getting rid of VS would be perfect !
But I configured the system (VS2008+ICL integration) to start and finish compiling with Intel ICL, not VC. The random behavior is the wrong thing. Most of the times it is OK.
Thanks for the advice !
Your last quoted INTEL_COMPILER guard would avoid reading stdint.h when ICL isn't engaged. The implication is you want to support switching the build compiler, which seems contradictory to supporting C99 in Visual Studio environment.
As ICL adds the option to set -Qstd=c99 and provide support for more recent C features than MSVC does on its own, you would expect ICL to provide its own stdint.h.
include_next has been problematical in dealing with the Intel C++ augmentation of the include file environment. I haven't seen examples of its use with Visual Studio, so I'll beg off discussing that or asking what you were trying to accomplish.
Dear Prince, Thanks for sharing your ideas. I only used the __INTEL_COMPILER check as a last resource. The same project in other path works OK without the checking for ICL. I have some 15 to 20 projects without any problem ,but lately, I have found this random error when creating a new project or simply copying a whole project from a path to other path (this is the only problem, all our include path are relative).
But any way, the solution was found for us. But the team of ICL-VC integration should think in this behavior because something is not working right in a few cases.