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\
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.
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.
I am trying to build the components of Live555 with Visual Studio 2013 64bit on Windows 7.
I have tried editing win32config and the *.mak files without success. I've been searching the internet for a few hours and trying all kinds of things with command prompts.
For some reason VS2013 x64 command prompt is still building 32bit static libs and I can't figure out why.
If anyone has any good ideas, that would be fantastic!
The win32config file that you get from the .tar.gz file requires substantial editing to make it compatible with recent SDK and MSVC++ releases. This is a version that produced a clean build:
NODEBUG=1
TARGETOS = WINNT
UI_OPTS = $(guilflags) $(guilibsdll)
CONSOLE_UI_OPTS = $(conlflags) $(conlibsdll)
CPU=amd64
COMPILE_OPTS = $(INCLUDES) $(cdebug) $(cflags) $(cvarsdll) -I. /EHsc /O2 /MD /GS /D "WIN64" /Oy- /Oi /D "NDEBUG"
C = c
C_COMPILER = cl
C_FLAGS = $(COMPILE_OPTS)
CPP = cpp
CPLUSPLUS_COMPILER = $(C_COMPILER)
CPLUSPLUS_FLAGS = $(COMPILE_OPTS)
OBJ = obj
LINK = link -out:
LIBRARY_LINK = lib -out:
LINK_OPTS_0 = $(linkdebug) ws2_32.lib /NXCOMPAT
LIBRARY_LINK_OPTS =
LINK_OPTS = $(LINK_OPTS_0) $(UI_OPTS)
CONSOLE_LINK_OPTS = $(LINK_OPTS_0) $(CONSOLE_UI_OPTS)
SERVICE_LINK_OPTS = kernel32.lib advapi32.lib shell32.lib ws2_32.lib -subsystem:console,$(APPVER)
LIB_SUFFIX = lib
LIBS_FOR_CONSOLE_APPLICATION =
LIBS_FOR_GUI_APPLICATION =
MULTIMEDIA_LIBS = winmm.lib
EXE = .exe
PLATFORM = Windows
rc32 = rc.exe
.rc.res:
$(rc32) $<
After you've edited this file, run the genWindowsMakefiles command from bash (or the CMD file). Next, start the x64 Visual Studio Command Prompt. Make sure you got the x64 native configuration flavor of it. Issue the following commands:
cd c:\projects\live\liveMedia
nmake -f liveMedia.mak
cd ..\groupsock
nmake -f groupsock.mak
cd ..\UsageEnvironment
nmake -f UsageEnvironment.mak
cd ..\BasicUsageEnvironment
nmake -f BasicUsageEnvironment.mak
cd ..\testProgs
nmake -f testProgs.mak
cd ..\mediaServer
nmake -f mediaServer.mak
Alter the first command to match the directory where you put the source.
TODO items: cleaning doesn't work, it tries to use the *nix rf command. Simplest workaround is del *.obj to force the compiler to rebuild the object files
the .exe files are built without a manifest. Shouldn't matter for the test programs, I assume you're only interested in the .lib files
it builds the release version of the libraries and executables, you'll have to tweak the COMPILE_OPTS to get a debug build.
In order to compile 64 bit native code with Visual Studio 2013, you
require professional edition.
Open the VS2013 x64 Native Tools Command Prompt
Then make sure you set C_COMPILER to "$(TOOLS32)\bin\amd64\cl" after correcting TOOLS32 to the VC/bin dir.
In order to compile 64 bit native code with Visual Studio 2013, you require professional edition.
Open the VS2013 x64 Native Tools Command Prompt
Then make sure you set C_COMPILER to "$(TOOLS32)\bin\amd64\cl" after correcting TOOLS32 to the VC/bin dir.
I am having problems running verify_tools to make a Wireshark build on Windows. The makefile fails with the following errors about not being able to find a file.
C:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
tools/win64-setup.sh: line 12: /cygdrive/c/Development/wireshark/tools/win-setup: No such file or directory
tools/win64-setup.sh: line 12: exec: /cygdrive/c/Development/wireshark/tools/win: cannot execute: No such file or directory
tools/win64-setup.sh: line 12: /cygdrive/c/Development/wireshark/tools/win-setup: No such file or directory
tools/win64-setup.sh: line 12: exec: /cygdrive/c/Development/wireshark/tools/win: cannot execute: No such file or directory
NMAKE : fatal error U1077: 'C:\Users\indiv\apps\cygwin\bin\bash.EXE' : return code '0x7e'
Stop.
To debug, I changed win64-setup.sh and made it print WIN_SETUP.
echo WIN_SETUP: [$WIN_SETUP]
exec $WIN_SETUP $#
The results were bizarre. Possibly because of some end-of-line issue.
C:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
]IN_SETUP: [tools/win-setup.sh
How can I fix or work around this problem?
The Wireshark build relies on all its supporting utilities coming from cygwin, except for cl, link, and nmake. Your path is set up such that some supporting utilities are coming from elsewhere in your environment. Like from an install of gnuwin32 or something.
For explanation purposes, let's say the variable CYGWIN is set to your cygwin path, like c:\cygwin\bin.
You are probably doing something like this, as suggested by the Wireshark wiki:
set PATH=%PATH%;%CYGWIN%
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x64
Instead of doing it that way, move cygwin earlier in the path search order so that executables always come from there. Then set up your Windows build environment so that Microsoft's link comes before cygwin's link.
set PATH=%CYGWIN%;%PATH%
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x64
Don't forget when you make these changes to restart your shell to wipe the old environment completely because SetEnv.cmd may have cached the old environment, which will prevent you from changing %PATH%.
And then you get this instead when you run the verify_tools rule:
c:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Checking for required applications:
cl: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/cl
link: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/link
nmake: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/nmake
bash: /usr/bin/bash
bison: /usr/bin/bison
flex: /usr/bin/flex
env: /usr/bin/env
grep: /usr/bin/grep
/usr/bin/find: /usr/bin/find
peflags: /usr/bin/peflags
perl: /usr/bin/perl
sed: /usr/bin/sed
unzip: /usr/bin/unzip
wget: /usr/bin/wget
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).