Bug with VS2013 RTM using SP1 Update 1 and xilink.exe

Bug with VS2013 RTM using SP1 Update 1 and xilink.exe

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.

 

14 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

Maybe I should add my software setup sequence, too.

  1. Installed VS2012
  2. Install Intel C++ Composer SP 1
  3. ... time passed ...
  4. Installed VS2013 RTM
  5. Uninstalled VS2012 (not needed anymore)
  6. 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.

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.

Yes, Win32 works.

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

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

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

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.

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

I am using workaround, found on internets (though very old post), modify the very end of *.vcxproj to look like this:

<PropertyGroup>
  <TrackFileAccess>false</TrackFileAccess>
</PropertyGroup>
</Project>

I hope this helps.

-- With best regards, VooDooMan - If you find my post helpful, please rate it and/or select it as a best answer where applies. Thank you.

引文:

Jennifer J. (Intel) 写道:

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.

-- With best regards, VooDooMan - If you find my post helpful, please rate it and/or select it as a best answer where applies. Thank you.

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.

引文:

VADIM G. (Intel) 写道:

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

-- With best regards, VooDooMan - If you find my post helpful, please rate it and/or select it as a best answer where applies. Thank you.

This issue is now fixed in Composer XE 2013 SP1 update #2 (compiler version 14.0.2.176)

登陆并发表评论。