restore cl to PATH

[TimP]

I've been having difficulty again on Windows 8.1.  ifort setup with Visual Studio 2012 Pro for X64, using command prompt, doesn't retain the path to CL after reboot and so refused to perform a link.  I can complete a build combining ICL and ifort by building .obj in the VS2012 cmd prompt and switching over to VS2010 shell prompt to link (I didn't ask for the VS2010 shell setup).

I can run vcvarsall.bat to get 32-bit CL on the path, but don't know an equivalent incantation to get the 64-bit CL.

This may be more of a Microsoft than an Intel tools issue, but surely there is a way to write a script which will put the Microsoft tools required by Intel compilers back on PATH.

I've been through the laborious route of removing all Intel and visual studio tools and re-installing from scratch (about 3 hours when not attempting the on-line installation), but it doesn't reliably fix this.

I attempted to file an IPS support issue but the site isn't responding.

[mecej4]

Tim, here is my solution to a similar problem: I have an older version (12.0.5) of IFort which was installed when I had Windows 7, and did not survive as an installed application after the upgrades to Windows 8.0 and 8.1. However, the installed files of the packages are still on the hard drive, and this batch file, when run from a plain CMD window, sets up the environment and the compilers (IFort and Cl) become available for 32-bit targets.

set SDKD=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A
set VCD=c:\Program Files (x86)\Microsoft Visual Studio 11.0
set IVF12D=c:\lang\Intel\ComposerXE-2011\
set MKLD=c:\lang\Intel\ComposerXE-2011\mkl
path %ivf12d%\bin\ia32;%mkld%\ia32\bin;%sdkd%\bin;%vcd%\common7\ide;%vcd%\vc\bin;%path%
set LIB=%IVF12D%\compiler\lib\ia32;%mkld%\ia32\lib;%VCD%\vc\lib;%SDKD%\lib;%LIB%
set include=%ivf12d%\compiler\include;%ivf12d%\compiler\include\ia32;%mkld%\include;%mkld%\include\ia32;%include%
path %ivf12d%\redist\ia32\compiler;%ivf12d%\redist\ia32\mkl;%path%
title IFC12-IA32

For 64-bit targets a similar batch file may be constructed, but it will be a bit more complicated since different components use different names for the architecture, such as x64, amd64 and intel64, and the include directories for MKL are further split into LP64 and ILP64.

[TimP]

My problem was in the basic PATH setting in environment variables.  This might have been guessed from the experience of installations working until reboot but then failing after reboot.

In the vast wisdom of Microsoft, vcvarsall.bat works for the default (setting up 32-bit CL) without any special PATH requirements, but depends on \windows\system32\ in PATH to work with the options to set up x64 compilers on 64-bit OS (remembering that system32 is where 64-bit system applications sit).

I'm grateful that removal of recent Intel tools doesn't leave behind as many bad entries as used to be the case, but it still seems necessary to know some requirements about initial PATH setup.

[mecej4]

Tim, now that you mention it, it is counter-intuitive that SYSTEM32 is where 64-bit utilities are located whereas SYSWOW64 is where the 32-bit utilities are placed. However, I must have become used to such properties of Windows over the years.

[Steven_L_Intel1]

Tim, would you please show the output of running the compilervars.bat or ipsxe-comp-vars.bat file at the start of your command prompt session? This should be invoking the appropriate Microsoft .bat file and there's an argument to that file to select 32-bit or 64-bit support.

[TimP]

When the problem occurs (which turned out to be due to problems with the initial Windows\System32 PATH setting before running compilervars.bat) the message is displayed from vcvarsall.bat about not setting up Visual Tools path correctly.  The problem isn't necessarily exposed when using icsxe-comp-vars.bat in the same situation.

vcvarsall.bat can set 32-bit paths OK but not 64-bit when the initial PATH has a problem.  So it was resolved by correcting the advanced environment PATH and restarting.