My problem is similar to this one: Problems generating solution for VS 2017 with CMake, but the solution doesn't work for me.
When run cmake in Developer Command Prompt for VS 2017, I got the error (from CMakeError.log):
LINK : fatal error LNK1104: Cannot open file "ucrtd.lib" [E:\Projects\My Project\VS\CMakeFiles\3.14.4\CompilerIdC\CompilerIdC.vcxproj]
But the file ucrtd.lib is located in the Windows Kits folder.
echo %LIB%
D:\Program Files (x86)\Microsoft Visual Studio 2017 Community\VC\Tools\MSVC\14.16.27023\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86;C:\Program Files(x86)\Windows Kits\10\lib\10.0.17763.0\um\x86;
dir "C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86\" /w /b
libucrt.lib
libucrtd.lib
ucrt.lib
ucrtd.lib
And I also try to manually run the build command listed in the CMakeError.log, it succeeds, no error.
CL.exe /c /nologo /W0 /WX- /diagnostics:classic /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\" /Fd"Debug\vc141.pdb" /Gd /TC /analyze- /FC /errorReport:queue CMakeCCompilerId.c
link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X86 /SAFESEH Debug\CMakeCCompilerId.obj
So it seems like cmake didn't recognize the environment variables, or did I miss some important steps?
cmake version is 3.14.4
visual studio version is 15.9.7
tl;dr:
Make sure HKLM\Software\Microsoft\Windows Kits\Installed Roots#KitsRoot10 is set to:
C:\Program Files (x86)\Windows Kits\10\
and NOT:
C:\Program Files\Windows Kits\10\
Full Explanation
On the LNK1104 error page, there's a relevant section titled, "Updated Windows SDK libraries", that reads:
This error can occur when the Visual Studio path to the Windows SDK is
out of date. It may happen if you install a newer Windows SDK
independently of the Visual Studio installer. To fix it in the IDE,
update the paths specified in the VC++ Directories property page.
Set the version in the path to match the new SDK. If you use the
Developer Command Prompt, update the batch file that initializes the
environment variables with the new SDK paths. This problem can be
avoided by using the Visual Studio installer to install updated SDKs.
Given this, the reasonable thing to do would seem to be to verify that the "Macro" pointing to the path containing the ucrt library files is in use.
However, this may not be enough. That Macro may be wrong.
This message from a Microsoft engineer says that some older Windows Kits improperly set the path to the ucrt. In these kits, they use the 64-bit program files path ("Program Files") instead of the 32-bit path ("Program Files (x86)"). However, during installation, if the path is already set, then it will not be updated by a subsequent Windows SDK installer.
So it's possible that your system will have the environment variable defined to the wrong value, resulting in Visual Studio failing to find the relevant library.
In that case, the Microsoft engineer's recommendation was to either update the offending registry value, or delete it then reinstall the Windows SDK.
Hey Alexander,
I've spoken to the Windows SDK team about this. In general, kit
installers are not supposed to set 'HKLM\Software\Microsoft\Windows
Kits\Installed Roots#KitsRoot10' to C:\Program Files\Windows Kits\10,
it is always supposed to point to C:\Program Files (x86)\Windows
Kits\10. However, there are Kits out there that make this mistake, and
the registry key is never updated if it already exists prior to any
kit installation. I believe whichever windows kit you've installed on
that system first had this issue.
That said, these issues will never go away entirely since there will
always be kits and machines floating around with this issue. I've
updated ucrt.props to be more defensive about this by checking the
Wow6432Node version first (which has not had this issue historically),
and only if that isn't present to fall back to the usual registry key.
This fix will be present in the next released Windows 10 SDK. In the
meantime, I recommend either deleting that reg key and reinstalling
the Windows 10 SDK, or simply directly modifying
HKLM\Software\Microsoft\Windows Kits\Installed Roots#KitsRoot10 to
point to C:\Program Files (x86)\Windows Kits\10 (the same effects of
the deleting the reg key and reinstalling, but less error prone).
Hope this helps!
Steve Wishnousky Senior Software Engineer - Visual C++ Libraries
stwish#microsoft.com
(quoted here because of concerns about the long-term availability of the message at the link)
As described here, if you're on VS2022 and your installed Windows SDK is version 10.0.19041.0 (which is what installs with VS2022 as the default as of this writing), then you may have run into this.
The solution in that case is to uninstall that SDK version and install a different one.
As mentioned in this CMake forum, it may be necessary to explicitly tell CMake which specific Windows version you have installed. Considering you have version 10.0.17763.0 installed, including the following definition will direct CMake to that version:
cmake -DCMAKE_SYSTEM_VERSION=10.0.17763.0
Here are the docs for CMAKE_SYSTEM_VERSION.
Related
I'm trying to configure CMake 3.24.2 to generate a Visual Studio 2019 project that uses ccache to cache the output of previous builds. For that, I'm following alternative #1 from ccache's docs, where I'm trying to configure CMake to point the compiler to a copy of ccache which I've dumped in C:/tools/ccache/cl.exe. For that purpose I'm setting CMAKE_CXX_COMPILER to point to my ccache.exe, and I'm generating the project with the following command.
cmake.exe -DCMAKE_CXX_COMPILER=C:/tools/ccache/cl.exe -G "Visual Studio 16 2019" -A Win32 -DCMAKE_INSTALL_LIBDIR=lib/win/Release/x86 -S D:\proj\testproject -B D:\proj\testproject\cmake-build-release
However, this does not work and the vs2019 project keeps on pointing to the original cl.exe command. Here's an except I've taken from D:\proj\testproject\cmake-build-release\CMakeFiles\CMakeOutput.log:
The system is: Windows - 10.0.19041.0 - AMD64
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded.
Compiler: C:/tools/ccache/cl.exe
Build flags:
Id flags:
The output was:
0
Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 2/11/2023 4:51:26 PM.
Project "D:\proj\testproject\cmake-build-release\CMakeFiles\3.24.2\CompilerIdCXX\CompilerIdCXX.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug\".
Creating directory "Debug\CompilerIdCXX.tlog\".
InitializeBuildStatus:
Creating "Debug\CompilerIdCXX.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30133\bin\HostX64\x86\CL.exe /c /nologo /W0 /WX- /diagnostics:column /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc142.pdb" /external:W0 /Gd /TP /analyze- /FC /errorReport:queue CMakeCXXCompilerId.cpp
CMakeCXXCompilerId.cpp
(...)
Apparently the Visual Studio 2019 project does get the hint that it should use C:/tools/ccache/cl.exe, but for some unknown reason its ClCompile entry points to the original cl.exe.
Does anyone know what's going on for the Visual Studio 2019 insisting on not using the C++ compiler passed with CMAKE_CXX_COMPILER?
This happens because the original cl.exe is inferred from the chosen generator "Visual Studio 16 2019".
In order to switch to another compiler you should use other generator e.g. Ninja or Unix Makefiles.
I build C++ code inside Windows container using Microsoft Visual C++ Build Tools 2015
msbuild /p:Configuration=Debug essentially runs cl.exe with /MDd option and produces unusable executable - see below.
/p:Configuration=Release uses /MD and makes perfectly fine executable.
Sample code hello-world.cxx:
#include <iostream>
int main()
{
std::cout << "Hello World!";
}
Compiling with /MDd:
> cl.exe /EHsc /MDd hello-world.cxx
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello-world.cxx
Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:hello-world.exe
hello-world.obj
> echo %ERRORLEVEL%
0
> hello-world.exe
...nothing is printed here...
> echo %ERRORLEVEL%
-1073741515
Compiling with /MD:
> cl.exe /EHsc /MD hello-world.cxx
...
> hello-world.exe
Hello World!
> echo %ERRORLEVEL%
0
Here is the relevant part of my Dockerfile:
FROM microsoft/windowsservercore
...
# Install chocolatey ...
...
# Install Visual C++ Build Tools, as per: https://chocolatey.org/packages/vcbuildtools
RUN choco install -y vcbuildtools -ia "/InstallSelectableItems VisualCppBuildTools_ATLMFC_SDK"
# Add msbuild to PATH
RUN setx /M PATH "%PATH%;C:\Program Files (x86)\MSBuild\14.0\bin"
# Test msbuild can be accessed without path
RUN msbuild -version
As you can see I install Visual C++ Build Tools 2015 via choco package.
I've read documentation: https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library
So /MDd defines _DEBUG and also places MSVCRTD.lib into the .obj file, not MSVCRT.lib
On my laptop I have full Visual Studio installed and it builds fine.
I've compared MSVCRTD.lib that I have installed under C:\Program Files (x86)\Microsoft Visual Studio 14.0 and on both systems files are the same.
Confused...
SOLVED
Container has no GUI, and compiled .exe tries to show GUI dialog with the message:
"The program can't start because ucrtbased.dll is missing from your
computer. Try reinstalling the program to fix this problem."
(found this when running built .exe in a similar environment but with GUI)
Interestingly C++ Build Tools 2015 installed these dll-s under:
C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt\
C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\
However when .exe runs it can't find them.
On full VS installation I found these files also copied under
C:\Windows\System32\
C:\Windows\SysWOW64\
Reinstallation of C++ Build Tools helped, however it's slow and feels weird.
So I've ended up just copy-ing those files manually instead.
Added to Dockerfile:
RUN copy "C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt\ucrtbased.dll" C:\Windows\System32\
RUN copy "C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\ucrtbased.dll" C:\Windows\SysWOW64\
I am trying to compile CUDA code from the command line using CUDA toolkit version 5.0 and the Visual Studio 2010 Professional compiler. In response to the following,
nvcc -c AddVectors.cu -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin"
I get the following error message
nvcc : fatal error : Visual Studio configuration file '(null)' could not be found for installation at 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/../..'
I also get this error message when Rebuilding within the VS 2010 IDE, but not when I just plain Build.
I am by no means a Visual Studio expert, but what is curious about the error message for me is that nvcc seems to exit the compiler directory I have specified and search upward from there VC/bin/../..
Why is it doing this? Why does it need anything other than the compiler executable in VC/bin/ and what is the role of the "Visual Studio configuration file" in all of this?
And, last but not least, how do I resolve this?
EDIT: My environment and search path are
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\mjacobson\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=WAA04087-RD
ComSpec=C:\Windows\system32\cmd.exe
CUDA_BIN_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\bin
CUDA_INC_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\include
CUDA_LIB_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\lib\x64
CUDA_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\
CUDA_PATH_V4_2=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.2\
CUDA_PATH_V5_0=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\
C_IA64_REDIST11=C:\Program Files (x86)\Common Files\Intel\Shared Files\cpp\
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\mjacobson
LOCALAPPDATA=C:\Users\mjacobson\AppData\Local
LOGONSERVER=\\SVRAABKP01
NUMBER_OF_PROCESSORS=12
NVCUDASAMPLES5_0_ROOT=C:\ProgramData\NVIDIA Corporation\CUDA Samples\v5.0\
NVCUDASAMPLES_ROOT=C:\ProgramData\NVIDIA Corporation\CUDA Samples\v5.0\
NVTOOLSEXT_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\nvToolsExt\
OS=Windows_NT
Path=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\bin\;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\libnvvp\;C:\Program Files (x
86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Common Files\Intel\Shared Files\cpp\bin\ia64;C:\Program Files\AccelerEyes\Jacket\engine\bin
64;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\ATI Technologies\ATI.ACE
\Core-Static;C:\Program Files (x86)\NTRU Cryptosystems\NTRU TCG Software Stack\bin\;C:\Program Files\NTRU Cryptosystems\NTRU TCG Software Stack\bin\;C
:\Program Files\Wave Systems Corp\Gemalto\Access Client\v5\;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program Files (x86)\Common
Files\Roxio Shared\10.0\DLLShared\;C:\Program Files\MATLAB\R2013b\runtime\win64;C:\Program Files\MATLAB\R2013b\bin;C:\Program Files\MATLAB\R2012b\runt
ime\win64;C:\Program Files\MATLAB\R2012b\bin;C:\Program Files\Microsoft Windows Performance Toolkit\;C:\Program Files (x86)\Common Files\Xoran Technol
ogies;C:\Program Files\MATLAB\MATLAB Compiler Runtime\v81\runtime\win64;C:\Program Files\MATLAB\R2011b\runtime\win64;C:\Program Files\MATLAB\R2011b\bi
n;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Ser
ver\100\DTS\Binn\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 44 Stepping 2, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=2c02
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
RoxioCentral=C:\Program Files (x86)\Common Files\Roxio Shared\10.0\Roxio Central36\
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=C:\Users\MJACOB~1\AppData\Local\Temp
TMP=C:\Users\MJACOB~1\AppData\Local\Temp
USERNAME=mjacobson
USERPROFILE=C:\Users\mjacobson
VS100COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
windir=C:\Windows
CUDA nvcc is just a steering compilation driver, that means nvcc uses both MSVC compiler and the CUDA compiler to perform his actions.
In a Windows environment you need to pay attention to several things before starting the compilation, make sure to review all of these:
Make sure you have enough privileges to run/write compilation chain programs into your paths. If you're admin on a home personal computer, in order to debug your problem, make sure to run all of the below commands and programs with administrative privileges (if that solves the issue, it was it!)
Environment variables are used to set the appropriate compiler and toolkit paths besides drivers locations. Assuming a clean and fully functional installation of both CUDA 5.0 toolkit and MSVC2010 Pro, in order to compile your 64-bit CUDA code with the x64 version of MSVC2010 the best way to set everything up properly is to run the Visual Studio x64 Command Prompt. You can find this into the start menu Visual Studio 2010/Tools/Visual Studio x64 Command Prompt (I suppose also a cross-platform x64 could work for this). Remember to run it with administrative privileges (Amministratore == Administrator in my birth-language in the screen below)
Notice in the above screenshot the "Setting environment.." line: that makes sure all of the appropriate environment variables relative to the x64 version of the MSVC compiler. From the log you posted nvcc should be immediately found and be able to detect the compiler you're supplying to it.
Programs which frown upon executables calling other executables whose work files are inside administrative-righted folders might need to be dealt with: in simple terms anti-viruses defenders (e.g. Comodo) and active protections filters may prevent nvcc and the tools it uses from getting their work done, make sure to disable these if you encounter warnings / problems while debugging your issue.
Just to be clear about something else: VC/bin is the x86 version of the MSVC compiler, VC/x64 is the one you're interested in (also often referred as amd64), VC/ia64 is for the IA64 architecture (a proper 64 bit architecture, x64 systems are just x86 systems "rendered" 64 bit.. they weren't born 64 bit).
When compiling your project from the MSVC IDE make sure of the admin privileges, no active protection programs on and that you're either properly matching the x64 project type with the CUDA C/C++ architecture targeted
Make sure there are no mismatches in both the project properties and single .cu files properties. Make sure that (with a verbose output active) there's no -m32 flag when compiling stuff in a 64 bit project (or at least if you know what you're doing).
I am trying to compile Cuda SDK examples but I am getting "MSB3721 error" since "nvcc" is "exited with code 1". Complete output:
"C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA
4.2.targets(361,9): error MSB3721: The command ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.2\bin\nvcc.exe"
-gencode=arch=compute_10,code=\"sm_10,compute_10\" -gencode=arch=compute_20,code=\"sm_20,compute_20\" -gencode=arch=compute_30,code=\"sm_30,compute_30\" --use-local-env --cl-version 2010 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64" -I"./" -I"../../common/inc"
-I"../../../shared/inc" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.2\include" -G --keep-dir "x64\Debug" -maxrregcount=0
--machine 64 --compile -g -Xcompiler "/EHsc /nologo /Od /Zi /MTd " -o "x64/Debug/bandwidthTest.cu.obj" "C:\ProgramData\NVIDIA
Corporation\NVIDIA GPU Computing SDK
4.2\C\src\bandwidthTest\bandwidthTest.cu"" exited with code 1."
Cuda toolkit 4.2 is used on Win7 x64 Ultimate system with VS2010 Ultimate.
The error remains when the "win32" option in "Configuration management" is used.
Are there any suggestions?
!!!!! Finally after reading all available NVIDIA manuals about "Getting started with CUDA" after reinstalling Win7+VS2010+CUDA drivers more than 10 times after building a new computer (Z77 mobo + i7 + GTX550Ti) and after waiting for months the NVIDIA forum resurrection I found out that the problem with the nvcc build error "exited with code 1" was disappeared when the "Run as administrator" option was selected on the VS2010 shortcut on my desktop!!!!!!
Although I was using an administrator account (the only account on the PC) it was impossible to build any of the CUDA Examples. The executables were running without any problem but I couldn't build the source code using VS2010!
!!!!!Thank you all for your support!!!!!
I would try to start from scratch. Remove CUDA, Nsight, and Visual Studio. Reboot. Manually remove any program folders that might be left. I can't guarantee that it's safe to remove these, but if any other NVIDIA or Microsoft products break because of this, I'd just fix those after having fixed CUDA:
C:\Program Files (x86)\Microsoft Visual Studio 10.0
C:\Program Files (x86)\Microsoft Visual Studio 9.0
C:\Program Files (x86)\NVIDIA Parallel Nsight 2.1
C:\Program Files (x86)\NVIDIA Parallel Nsight Monitor 2.1
C:\Program Files\Microsoft Visual Studio 10.0
C:\Program Files\NVIDIA GPU Computing Toolkit
Manually remove any left over app data folders:
C:\Users\<your user folder>\AppData\Roaming\NVIDIA
C:\Users\<your user folder>\AppData\Roaming\NVIDIA Corporation
You might want to look for registry keys as well.
Then reinstall everything. Nsight comes with CUDA, so I'd first install VS then Nsight. That should be all that is required. Then, create a CUDA project from scratch.
You might want to look at this thread, maybe it helps you with your problem:
How to Compile CUDA App is Visual Studio 2010?
I would like to build boost using two different compilers, MinGW and Visual C++ 2010 Express, using bjam:
bjam toolset=gcc,msvc variant=release link=static,shared threading=multi install
The problem is that I do not have bjam. I could not find it in the Boost directory, and the one I downloaded from somewhere else was a wrong version.
I should be able to build it from the code in Boost, but how? I read that I must launch build.bat from the BOOST_ROOT/tools/jam/src directory, but that directory does not exist !
Thank you!
Platform: Windows7
Compilers: MinGW and Visual C++ 2010 Express
Update:
I have been able to get bjam with: bootstrap.bat gcc
Then, launching bjam with the previous parameters, I only get libraries for MinGW (.dll and .a).
This is an extract of the error messages I get with regard to Visual C++ 10:
...
call "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi\plain_report_formatter.obj.rsp"
...failed compile-c-c++ bin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi\plain_report_formatter.obj...
...
...skipped <pbin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi>boost_unit_test_framework-vc100-mt-1_48.dll for lack of <pbin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi>compiler_log_formatter.obj...
...
common.mkdir bin.v2\libs\thread\build\msvc-10.0\release\threading-multi
common.mkdir bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32
compile-c-c++ bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\thread.obj
\Microsoft was unexpected at this time.
...
call "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\thread.obj.rsp"
...failed compile-c-c++ bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\thread.obj...
compile-c-c++ bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\tss_dll.obj
\Microsoft was unexpected at this time.
...
...skipped <pC:\Boost\lib>boost_thread-vc100-mt-1_48.lib for lack of <pbin.v2\libs\thread\build\msvc-10.0\release\threading-multi>boost_thread-vc100-mt-1_48.lib
...
Trying to use:
bootstrap.bat vc100
I get the error: "Unknown toolset: vc100"
With either:
bootstrap.bat vc10
or:
bootstrap.bat mingw
I get: "\Microsoft was unexpected at this time."
Changing project-config.jam did not help.
So, I did a big step forward, but vc10 is not working, yet...
There is a bootstrap.bat in your boost directory. Run it.
It will build bjam automatically (probably using visual c++).
The directory structure in boost has changed in recent version, I think.
The sources for bjam are in tools/build/v2/engine. Run build.sh mingw from that directory using MinGW shell, and it should build bjam.exe and b2.exe and place them in tools/build/v2/engine/ntx86. Copy b2.exe to the boost root directory. You should then be able to build Visual c++ libraries with b2 toolset=msvc.
Hope that helps.
In my case, the solution from jork works!
I searched the bjam.exe file and found it located in the tools/build/src/engine directory and just copied it to the boost root directory. But I have to say this is awful, I felt like the codebase writer is trying to hide sth. And I found that my bjam.exe is exactly is the same size with b2.exe, which is 404KB.
I will turn back later to ensure that I solved this issue.