- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
its not possible to compile VS2013 RTM projects which are x64 using the new SP1 Update 1 of the Intel C++ Compiler.
Replicate:
in Visual Studio 2013 RTM
- New Project
- Visual C++ / Win32 / Win32 Console Application
- Change project to Release and x64
- Verify in Configuration Manager that everything is set to Release/x64
- Compile default project (using MS compiler) = All OK
- Now right click on project and switch to Intel C++
- Compile ..
Result:
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\Intel64\xilink.exe" @C:\Temp\tmpdcfe543c769c42f39386e2358d6cbd13.rsp". The operation identifier is not valid.
or in older projects you get other erros but all contain xilink.exe problems. Maybe thers is a string error to call xilink with too many or missing "" ?
Once the problems is identified, plz provide a quick fix description as it takes too long for Update 2 to arrive.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe I should add my software setup sequence, too.
- Installed VS2012
- Install Intel C++ Composer SP 1
- ... time passed ...
- Installed VS2013 RTM
- Uninstalled VS2012 (not needed anymore)
- Installed Intel C++ Composer SP 1 Update 1 with VS2013 support
Maybe something broke during these install/uninstall situations. But the above scenario should be supported as it will be quite common.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the same issue with a completely clean install of Windows 8.1 + VS2013 RTM + Intel C++ Composer SP1 Update 1, so I'm guessing it's not related to old version uninstall/install problems.
It's the identical issue with the x64 configuration and TRK0002 error. Win32 configurations work fine as far as I can tell.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, Win32 works.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I saw the same issue on Windows 8.1. But it works on the Windows 8 + VS2013.
Andre, is your machine also Windows 8.1?
Jennifer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jennifer,
thanks for looking into this bug.
I use Win7 x64 SP1 with all updates using (superslow) Samsung N230 Atom 450 CPU netbook. This seems to be a scripting bug. I noticed that x64 Debug will compile sometimes with Intel C++ set as the project build target but if you check the logs you will see that infact MSC++ compiler was used. Some scripts messed it up. (Do we have a digital McGyver here ?)
I have no clue how the compiler switching is done in VS but it seems the problem can be found somewhere in that area.
Maybe try some VM testing with a powerful machine to get closer to the problem. Sry that I can't do VM testing with Atom CPU before I get grey hair ;)
Guess its just some mistake to call xilink with a wrong character around .. but I thought you guys doublecheck project builds before you release code to the public ? High paid degree professionals ? To download 1.5 gig of non working code is pretty lame for your company considering the work (time) to revert back to a previous version to get production working to earn money.
Intel is still the same today it was compared to some years ago. Unless their international Call Center is flooded with complaints they dont move a tick. Ignore, deflect and admit only if the legal department signs it off. Oh, unless you are a Premier and sign a NDA to keep mistakes a secret from the public. Thanks for wasting my time. I'm just a low profile customer.
Kind Regards,
Andre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've filed a high CQ about this issue. DPD200249390.
Strange that on the machines with old versions of Visual Studio, I do not see the problem. I'll update here if we found any workaround. Sorry about it.
Jennifer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andre,
Thanks for reporting the issue. Before the solution is found you may try the following workaround (if it's suitable for you). It works from cmdline via msbuild utility:
1. Open VS2013 x64 native command prompt
2. cd <directory of your project>
3. msbuild /t:Rebuild /p:Platform=x64
Regards,
Vadim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Andre for reporting this issue. Our IDE team has identified the problem and also provided a work-around. It's related to a late change in the VS2013. It will be fixed in the next update.
The work-around is very easy. Please see this article for the details on the work-around.
Thank you,
Jennifer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using workaround, found on internets (though very old post), modify the very end of *.vcxproj to look like this:
[cpp]
<PropertyGroup>
<TrackFileAccess>false</TrackFileAccess>
</PropertyGroup>
</Project>
[/cpp]
I hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jennifer J. (Intel) wrote:
The work-around is very easy. Please see this article for the details on the work-around.
This workaround is working well for me, even better than mine in previous post. Thank you Jennifer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi VooDooMan,
Your workaround could work, but it has a side effect - it prevents file tracker from using and that results in rebuilding your sources every time you *build* the project (not rebuild). In other words it stops incremental building.
Use Jennifer's workaround. Or alternatevely you may try the following:
Open Toolset.props and move the following line
<_IsNativeEnvironment Condition="'$(PROCESSOR_ARCHITEW6432)' == 'AMD64' OR '$(PROCESSOR_ARCHITECTURE)' == 'AMD64'">true</_IsNativeEnvironment>
to be right after
<BaseToolsetPropsFound Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\$(BasePlatformToolset)\Toolset.props')">true</BaseToolsetPropsFound>
Thanks, Vadim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
VADIM G. (Intel) wrote:
Hi VooDooMan,
Your workaround could work, but it has a side effect - it prevents file tracker from using and that results in rebuilding your sources every time you *build* the project (not rebuild). In other words it stops incremental building.
Use Jennifer's workaround.
Yes, I have later realised this fact. I was using my workaround before I was not successful while googling for the problem resolution, and later I found this topic and Jennifer's advice.
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This issue is now fixed in Composer XE 2013 SP1 update #2 (compiler version 14.0.2.176)

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page