Below is the error message when I run "scons" to compiler in windows7:
-----------------------------------------------------------------------------------
'cl' is not recognized as an internal or external command,
operable program or batch file.
scons: *** [out\windows-x86-MD-unicode-vs2008-rel\obj-static\src\featuresets\ada pters\im-history\AddToChatRoomHistoryVisitor.obj] Error 1
scons: building terminated because of errors.
-----------------------------------------------------------------------------------
I have added path to environment variables already, but still met this problem.
Below is the PATH info of environment variables:
--------------------------------------------------------------------------------------------
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v
1.0\;C:\Program Files\CREDANT\Shield v7.1\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Fil
es\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\TortoiseSVN\bin;C:\Python27;C:\cygwin64\bin
;C:\Python27\scons-2.3.1;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program File
s\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Progra
m Files (x86)\Microsoft Visual Studio 10.0\VC\bin;C:\Python27\Scripts;C:\Program Files (x86)\Microso
ft Visual Studio 10.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include
--------------------------------------------------------------------------------------------
The location of the cl.exe executable is not in the system PATH environment variable.
In other words the cmd.exe command line processor has been asked to run the cl.exe executable but it can't find it. It is either not in the PATH or not installed.
I have added path to environment variables already, but still met this problem.
To test this open a command prompt and type in:
cl.exe -?
SCons has logic to find the location of the visual studio install and set the path and other environment variables needed by visual studio tools by inspecting the registry and also default install locations.
If it's failing for you then you should produce a debug log and pastebin it somewhere for us to see.
use:
set SCONS_MSCOMMON_DEBUG=%TEMP%\SCONS_MSVS_DEBUG.log
and then runs scons from the same shell. The log will be in
%TEMP%\SCONS_MSVS_DEBUG.log
You might also try the latest version of SCons 2.4.1 as I note there were some fixes for MSVS/MSVC in later versions. But in theory 2.3.1 should find Visual Studio 2010..
Simply do window search for cl.exe, and add that path to PATH variable, save it. Close the existing open command and reopen it it before executing cl.exe. Hope this will work.
I was having the same issue and found a better way to fix it from #bdbaddog answer to get the debug log from set SCONS_MSCOMMON_DEBUG=%TEMP%\SCONS_MSVS_DEBUG.log SCons seem to find the cl.exe
00073ms:MSCommon/vc.py:_check_cl_exists_in_vc_dir#588:checking for cl.exe at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx64\x64\cl.exe:
00073ms:MSCommon/vc.py:_check_cl_exists_in_vc_dir#590:found cl.exe!:
And scons env env['ENV']['PATH'] has the cl.exe path but it doesn't use it, So I just updated the session path using scons path like below and it worked
os.environ['PATH'] = env['ENV']['PATH']
Related
i just installed qt creator 5.10 and i opened a simple widget application this is the error that i get even without running the application
:-1: error: Failed to retrieve MSVC Environment from "D:\pograml files\visual studio2\VC\Auxiliary\Build\vcvarsall.bat":
'chcp' is not recognized as an internal or external command,
operable program or batch file.
'wmic' is not recognized as an internal or external command,
operable program or batch file.
i haven't found any solutions for this, if anyone could help me i would be very thankful
When Qt starts, I used to get a list of 10 errors related to MSVC kit because each detected MSVC platform compiler has an Initialization script for setting environment. like:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat x86_amd64
I traced the failure by running all Initialization one by one on same command line (cmd) window; In the beginning I used to run only Initialization for x86_amd64 which runs without errors thus I didn't notice anything wrong. But on same window running Initialization for next compiler " ...\vcvarsall.bat x86_amd64" the error appeared which in my case was something like:
" ..program Files\MySQL\Utilities xxx was not expected at this time"
I just checked and found that path does not exist at all in my storage, so I removed it from PATH system env settings, and surprised things went normal after that!
To add to the answer of #John Wesley, I too had to alter my system's PATH enviroment variable to fix the "failed to retrieve msvc environment" error. However, my problem was slightly different.
In short, remove any unused directories from your PATH.
To explain, my PATH contained the following entries in the following order:
C:\Program Files (x86)\Common Files\Oracle\Java\javapath;
C:\ProgramData\Oracle\Java\javapath;
C:\Program Files (x86)\Intel\iCLS Client\;
C:\Program Files\Intel\iCLS Client\;
C:\Windows\system32;
C:\Windows;
C:\Windows\System32\Wbem;
[lots more enties followed...]
Hence my case was different to John's because it already had the required entries of:
C:\Windows\system32;
C:\Windows;
C:\Windows\System32\Wbem;
The fix for my system was to delete the first two entries (which I do not need because I manually set my Java paths). After I did that, I reopened Qt Creator and it worked!
It has been working for the past week without problem, however, sometimes the message "failed to retrieve msvc environment" still pops up for a moment, but then disappears again.
I met this error building qt project in Qt Creator. then solved by adding some paths to my system path, which not included them before.
C:\Windows\System32
C:\Windows
C:\Windows\System32\Wbem
Then reopen Qt Creator.
I faced the same problem as you. I use Visual Studio 2017 Community Edition with Qt 5.6.0. Windows 10.
In the beginning, I used "Visual Studio Installer" to repair. However it does not work.
Then I append "C:\Windows\System32" to "PATH" variable to Environment variables" since chcp is a exe in System3 and somehow I cannot find "C:\Windows\System32" in "PATH".
After that, I delete the Visual Studio (C:\Program Files (x86)\Microsoft Visual Studio) directly from File Explorer. ( I shift+deleted it )
Then re-install the "Visual Studio 2017" again.
It works!
I do not know which step is important. I think to add System32 to PATH variable and re-install VS2017 may the solution
In my case, I found the problem in my System Path variable. If the Path contains double quote anywhere, Qt emits this error.
I have meet the "error: Failed to retrieve MSVC Environment" for no reason. I deleated the debug file of my project and it does work.
I have build a Qt project (qwt) using the vs2013 compiler in Qt creator. When I open the .pro file and look at the build steps I see:
qmake: qmake.exe qwt.pro -r -spec win32-msvc2013
Make: nmake.exe in C:\qwt-6.1.2
When I build the project, all goes fine and the project is build without errors. So far so good.
However when I try to build this project using the command line I get errors during the nmake step. I have used the same commands as above (and I'm sure that I'm using the same versions of qmake/nmake).
...\QtCore\qglobal.h(38) : fatal error C1083: Cannot open include
file: 'stddef.h': No such file or directory
My question is, what does Qt do more so that the project does build in Qt creator and not from the command prompt? And how can I copy this behaviour in the command prompt? I'm doing this so I can make a batch file that builds the project (on a machine that does not have Qt creator installed).
In order to use the Visual Studio compilation environment from the command-line you need to call the vcvars batch script to set up the paths correctly.
Either call the vcvars64.bat in the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64 folder (that is for VS2013, you can replace the "12.0" with whatever visual studio version you have).
Or the vcvars32.bat in the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin folder.
Or use the vcvarsall.bat x86 or vcvarsall.bat x64 calls for the script in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC
Alternatively Visual Studio creates shortcuts in the start-menu called along the lines of VS2013 x64 Native Tools Command Prompt which call those scripts.
It's likely to be that Qt Creator has added additional variables into the build environment, which are not presented when you try to compile manually through cmd.
If you look within Qt Creator under the Projects section there's Build information. Expand the Build Environment information and check to see if there's anything in there different to your machines global environment settings.
i have installed TBB setup for windows 7 and want to execute code in it.i don't have visual studio setup and i have code blocks IDE. i want to execute my TBB code in it.Pls Help to configure Code Blocks.
I have done Linker settings i.e i have included libraries from this path
C:\Program Files\Intel\Composer XE 2013\tbb\lib\ia32\
and i have set search directory to
C:\Program Files\Intel\Composer XE 2013\tbb\include\tbb
still also when i compile it gives error tbb/task_scheduler_init.h :No such file or directory.
Can anyone pls suggest how to run TBB code in windows??
I have set the search directory to
C:\Program Files\Intel\Composer XE 2013\tbb\include\tbb
Pretty clear from the error message and the location of the file you gave that you should have set the search directory to
C:\Program Files\Intel\Composer XE 2013\tbb\include
I can compile from the command line by running vcvarsall.bat, then running cl.exe with my source file as the only argument. The problem is that just running cl.exe without first setting up the environment using the aforementioned batch file causes errors due to "missing libraries".
I can picture a couple of workarounds to this, for example creating a batch file in my project directory that includes vcvarsall.bat and does all the compiling. That seems to me to be a very cumbersome and inflexible solution though. I would much prefer to be able to compile and run any C or C++ file from Vim like one would in Unix:
:nnorebind <F5> :! g++ %<CR>
I don't want to add the pile of paths that vcvarsall.bat adds to the environment permanently though. I don't know how to phrase my question any better than this: How do I set up Vim to be able to use the Visual Studio 2010 C++ compiler?
You can update environment variables from within Vim. For instance, to add "c:\foo" to the start of your PATH:
let $PATH='c:\\foo;'.$PATH
I copied the relevant portions of my vcvars*.bat file to my vimrc:
if !exists("visual_studio_paths_added")
let visual_studio_paths_added = 1
let $PATH="C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\Common7\\IDE;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\BIN;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\Common7\\Tools;C:\\Windows\\Microsoft.NET\\Framework\\v3.5;C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\VCPackages;C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\bin;".$PATH
let $INCLUDE="C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\ATLMFC\\INCLUDE;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\INCLUDE;C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;".$INCLUDE
let $LIB="C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\ATLMFC\\LIB;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\LIB;C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\lib;".$LIB
let $LIBPATH="C:\\Windows\\Microsoft.NET\\Framework\\v3.5;C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\ATLMFC\\LIB;C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\LIB;".$LIBPATH
endif
Adapt as needed given your version of Visual Studio and installation directory.
In my case, I put this in a function. I call :vcvars when I want to work with Visual Studio. But you could just have those changes always included.
Expanding on the comment by David RodrÃguez - dribeas, and seeing how vcvarsall.bat accepts parameters, I found it helpful to have the following file in my source trees:
vc.bat:
call "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat" amd64 & %*
Adjust MSVS version and platform as appropriate, or make them additional parameters if you like. The %VS...COMNTOOLS% environment variable is set by the MSVC installer, which makes the above independent of the actual installation path.
This allows me to run any <command> in the proper MSVC environment by running it as:
vc.bat <command>
If called without parameters, it will just set the environment for the current shell without executing any further commands.
If you want to go one step further, there is CMake, a meta-buildsystem that allows you to generate Unix Makefiles, MSVC solutions and several other buildfile types from a single (CMake syntax) configuration. One of the buildfile types supported on Windows are NMake Makefiles... and nmake <target> on Windows handles just about as well as make <target> does on Unix.
Mud's solution did not work for me with Visual Studio 2017 Community. Paths are different. I think DevSolar's way to use vcvarsall.bat is more reliable, as it lets VS take care of the correct paths.
As I don't want to carry around a .bat file with my vim config, I was looking for a solution to work only inside the .vimrc:
Add vcvarsall.bat to your PATH. In my case c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC.
Put the following in your .vimrc to compile current file by F8
nnoremap <F8> :!vcvarsall.bat && cl /EHsc % <CR>
I'm trying to build boost on windows 7 64-bits. Running bootstrap gives
execnt.c(29) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
and some others. I have visual studio 9.0 and the places where I have windows.h is in
C:\Program Files (x86)\Microsoft SDKs\Windows\v5.0\Include**W**indows.h, with capital W
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include**W**indows.h
C:\Program Files (x86)\Microsoft Visual Studio 9.0\SmartDevices\SDK\Smartphone2003\Include\windows.h
I have the SDK installed and even fully reinstalled Visual studio. Any way I can fix this?
Small update: I installed Visual C++ 2010 express and from the IDE I can include and the test project compiles just fine, but when I use the prompt NO projects can find the header
Try running the boost build from a VS console rather than trying to run 'cmd'. It's probably somewhere in the start menu entry for VS (used to be anyway). It used to also be available from VS itself under tools, but I think they removed it there.
This version is just cmd, but it runs a batch script that sets a bunch of very important environment variables.
For future reference of anyone looking for the same error
I have installed visual studio without registry edition permission, so I had none of the environment variables set, those that boost libraries / libxml2 et al look for when calling the cl compiler
Giving myself permission to edit the registry and uninstalling/reinstalling all visual studio related programs solved it
Edit %VS90COMNTOOLS%vsvars32.bat with administrator privileges any way you like, eg.
runas /user:Administrator "notepad %VS90COMNTOOLS%vsvars32.bat"
Find the section
:GetWindowsSdkDirHelper
#for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\Microsoft SDKs\Windows" /v "CurrentInstallFolder"') DO (
if "%%i"=="CurrentInstallFolder" (
Change it to
:GetWindowsSdkDirHelper
#for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0a" /v "InstallationFolder"') DO (
if "%%i"=="InstallationFolder" (
When you install a newer version of the Windows SDK, it updates HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\CurrentInstallFolder to point to the newer version.
Unfortunately, the batch file that Visual Studio 2008 uses to set its paths uses this registry key to identify the location of the Windows SDK, so instead of pointing at the version of the Windows SDK that works with VS2008 (6.0a), it points to the the latest version to be installed.
Editing the registry is one option. A better option is to change the batch file so that it gets the right path from the registry, as above.