I'm trying to build project c++ on vs2017 but there error appear:
"The build tools for Visual Studio 2008 (Platform Toolset = 'v90') cannot be found " after navigation, I must download VS 2008 I have installed it, but problem still exist .
any Suggestion ?
You need:
An MSVC 9.0 compiler toolchain
https://wiki.python.org/moin/WindowsCompilers lists the products that have it:
VS 2008, "Visual C++" feature and "x64 compilers and tools" subfeature
Express edition only has x86 compilers
Do install SP1 on top of VS2008 -- in vanilla VS2008 installer, installation for many features, including x64 compilers, is broken
WinSDK 6.1
WinSDK 7.0
"Visual C++ Compiler for Python 2.7" package
MsBuild 4.0 toolset configuration files for the above toolchain. (These are the directories c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\<arch>\PlatformToolsets\v90\ with .props and .targets files in them)
The only product I know that has this package is VS 2010 ("Visual C++" feature and "x64 compilers and tools" subfeature).
(WinSDK 7.1 technically has it, too, but its setup is riddled with bugs and broken on an x64 system.)
(You can bypass the buggy installer though if you install <GRMSDK_EN_DVD.iso>\Setup\vc_stdx86\vc_stdx86.msi directly. Despite the name, it has toolset files for all 3 platforms.)
"Visual C++ Compiler for Python 2.7" package is not supported by these toolset configuration files. So if you use it, you'll need to either manually specify its location in one of registry values specified in .props, or modify .props to also look in HKLM\Software\Microsoft\DevDiv\VCForPython.
The projects are targeting the v90 platform toolset. The solution is to either open the .sln file with VS2008 (i.e. use the right tool), or spend some time updating the projects to target the latest platform toolset (i.e. VS2017). To do that, just right click each project, and go to Properties, then look at General | Windows SDK Version. You may have to fix compilation / linker errors following the project upgrade.
It is possible to upgrade the project file from the command line without opening it in Visual Studio. I was running into the same issue, and found another solution in the Microsoft documentation for Visual Studio (https://learn.microsoft.com/en-us/visualstudio/ide/reference/upgrade-devenv-exe?view=vs-2017).
Here are the steps:
Open the developer command prompt for you version of Visual Studio, e.g. 'Developer Command Prompt for VS 2017'.
Navigate to the directory of your project file.
Execute the following command: devenv myproject.sln /upgrade
I have a project that has only ever lived in Visual Studio 2017. It's a C++ dll, and up until this point I've had no problem building it from within the Visual Studio GUI. However now I'm trying to set up automation that will build the project on the command line and upload the output files to a desired location. Here's what I've tried so far (in a brand new Command Prompt):
cd C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>
vcvarsall amd64
cd C:\Users\me\development\MyProject
msbuild MyProject.slnl (or msbuild MyProject\MyProject.vcxproj)
And this gives me the error output
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140\Microsoft.Cpp.Platform.targets(57,5):
error MSB8020: The build tools for v141 (Platform Toolset = 'v141') cannot be found. To build
using the v141 build tools, please install v141 build tools. Alternatively, you
may upgrade to the current Visual Studio tools by selecting the Project menu or right-cli
ck the solution, and then selecting "Retarget solution".
[C:\Users\dev\development\MetaReme\MetaReme\MetaReme.vcxproj]
Let me reiterate that I've been successfully building within Visual Studio 2017 targeting the v141 toolset, it's just on the command line I'm having trouble. Within my Visual Studio Installer application I have the VC++ 2017 v141 toolset checked. I've looked on the filesystem and within C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\ there is no v141 folder.
Thanks!
Thanks guys! I was following https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line which says "By default, these tools are installed in drive:\Program Files (x86)\Microsoft Visual Studio version\VC\bin.". Obviously these docs are outdated... I was able to get it to work with the following commands
cd "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build"
vcvars64
cd "C:\Users\me\development\MyProject"
msbuild MyProject.sln
It says in the first part of the paragraph in the mentioned article:
In Visual Studio 2017, these are located in the VC\Auxiliary\Build subdirectory of the Visual Studio installation directory. In Visual Studio 2015, these are located in the VC, VC\bin, or VC\bin\architectures subdirectories of the installation directory, where architectures is one of the native or cross compiler options.
As you are using Visual Studio 2017, they should be in VC\Auxiliary\Build, like you found out.
Another way to find the correct .bat files would be through the command prompt shortcuts mentioned in the same article. First locate them by expanding start->Visual Studio Year, right click and find their location. Then check the location they are pointing to.
What I want to be done: Create a 64bit DLL on win7 that interacts with the Windows API including the OLE32.dll.
What I have got:
I am currently stuck. I download Visual Studio 2015 Community Edition. I tried to create a DLL there and on creation it generated everything but no dll. The program did not complain, everything was setup as in the tutorial but no dll file.
So I skipped this and downloaded Eclipse CDT. I set up using the Visual C toolchain and after minor issues I had my DLL generated. So I used Java to fire it up but it complained (I use JNA for integration) and it seams that I have a 32bit DLL.
So I searched the web and read and did stuff but I am totally lost. Since the Visual Studio 2010 Express edition came without a 64bit compiler I am not even sure if the Community edition of Visual Studio supports 64bit dlls this time.
I also have the Windows SDK v7.1 installed. I link to a library file ole32.dll. It contains the method CoCreateInstance which I require. I have to add this manually in order for the compiler to pick it up. If I switch to the 64bit dll version the compiler complains about the CoCreateInstance method can not be linked.
So basically I am lost here. A source on the web gave a work around for the 2010 Express being not able to create x64 DLL and it turned out that the hint was getting windows SDK since it it comes along with a compiler.
Also I noticed that CDT uses Visual Studio 10 files so I guess it is using this compiler.
I set to both compiler and linker the /machine:64 option. But the linker still complains that the obj file from the compiler is 32bit.
Any Ideas?
[Update]
The Compiler prints the following line so basically it is not able to compile 64bit version. Any idea how to replace it? As said it uses the Visual Studio 10 folder but I also have a Visual Studio 12 and 14 folder as well.
cl : Command line warning D9002 : ignoring unknown option '/machine:x64'
Well, I don't think '/machine:x64' is a cl option but it's one of linker option.
If you want to make some dll maybe with windows sdk or visual studio environment.
I am not sure that my solution is fit for yours or not, this is what i did for my 64-bit project to compile with eclipse and windows sdk 7.1.
I have two eclipse IDEs which are 32bit and 64bit neon version.
I choose a 64-bit one. You can check one of my answer about installation here. In my opinion, any version of them will be fine. It is your choice.
First step. run 'Windows SDK 7.1 Command Prompt from the start menu.
then, start my eclipse on the command window after changing 64-bit development level with command as follows.
Second Step. Setting up path variables to my project.
I have my own project with a properties window.
The important variable seems to be both LIB and PATH variable in my point.
I crosschecked this two variable, one was from the windows SDK's prompt window and another was current setting variables after installation.
SDK variables here
My final variables are
LIB:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Lib\amd64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\X64
PATH:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\VCPackages;;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin;;
C:\Windows\system32;C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
Third, I modified my linker flag as you see the picture below.
Finally, I compiled my project successfully.
Here is my build log.
Info: Internal Builder is used for build
cl /c /EHs /MD /Zi /nologo /Foutil.obj "..\util.c"
rc /Fo proc_view.res "..\proc_view.rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /EHs /MD /Zi /nologo /Foprocss.obj "..\procss.c"
link /machine:x64 /debug /nologo /OUT:Systemer.exe FreeList.obj LinkedList.obj proc_main.obj proc_view.res procss.obj util.obj Kernel32.lib Psapi.lib User32.lib
The last one had done with checking if my executable file was 64-bit or 32-bit with a dumpbin command.
That is all.
I think the Eclipse with MinGW or cygwin might be a better option.
I hope this is right for you.
After installing Visual Studio 2015 and running CMake on a previous project, CMake errors stating that it could not find the C compiler.
The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:4 (PROJECT):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:4 (PROJECT):
No CMAKE_CXX_COMPILER could be found.
I went searching for cl.exe in the Visual Studio folder,C:\Program Files\Microsoft Visual Studio 14.0, and could not find it.
How do I set up CMake to work on Windows with Visual Studio 2015?
I have found the solution. While the Visual Studio IDE installed successfully it did not install any build tools and therefore did not install the C++ compiler.
By attempting to manually create a C++ project in the Visual Studio 2015 GUI I was able to prompt it to download the C++ packages. CMake was then able to find the compiler without any difficulty.
Here is the solution that worked for me:
Open Visual Studio command prompt tool (as an administrator). On windows 10 it might be called 'Developer command prompt'.
Navigate to where you have the CMake executable
Run Cmake.exe
Proceed as usual to select build and source folder
Select the appropriate Visual Studio compiler and hit the configure button
Hopefully it should run without problems.
I looked in CMakeError.log file and found an error about cannot run 'rc.exe'
I searched and found this answer to copy RC.Exe and RcDll.Dll from the Microsoft SDKs bin to the VC bin, and then CMake worked.
Edit: The top answer to another question suggests that it's a PATH issue, so it could be enough to ensure the Microsoft SDK bin is in your PATH.
Those stumbling with this on Visual Studio 2017: there is a feature related to CMake that needs to be selected and installed together with the relevant compiler toolsets. See the screenshot below.
Make sure you are using the correct version of Visual Studio in the generator. I had incorrectly selected Visual Studio 15 when Visual Studio 14 installed.
If none of the above solutions worked, then stop and do a sanity check.
I got burned using the wrong -G <config> string and it gave me this misleading error.
First, run from the VS Command Prompt not the regular command prompt. You can find it in
Start Menu -> Visual Studio 2015 -> MSBuild Command Prompt for VS2015 This sets up all the correct paths to VS tools, etc.
Now see what generators are available from cmake...
cmake -help
...<snip>...
The following generators are available on this platform:
Visual Studio 15 [arch] = Generates Visual Studio 15 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
Optional [arch] can be "Win64" or "IA64".
...
Then chose the appropriate string with the [arch] added.
mkdir _build
cd _build
cmake .. -G "Visual Studio 15 Win64"
Running cmake in a subdirectory makes it easier to do a 'clean' since you can just delete everything in that directory.
I upgraded to Visual Studio 15 but wasn't paying attention and was trying to generate for 2012.
For me, I checked the CMakeError.log file and found:
[...] error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".
This is despite using Visual Studio 2017 on Windows 7. So it appears that CMake is trying to build its detection project with the Windows 8.1 SDK.
I used the Visual Studio installer to add that component and now CMake is happy as a clam.
Menu → Visual Studio 2015 → MSBuild Command Prompt for Visual Studio 2015. Then CMake can find cl.exe.
set PATH="c:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\";%PATH%
Change the upper path to where your Windows SDK is installed.
CMake can find rc.exe.
cd to the path of CMakeLists.txt and do:
md .build
cd .build
cmake .. -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
cmake --build .
The param after -G should be fetched by CMake. Use --help; you may or may not have the generator.
I ran into the same issue and fixed it by relaunching the Visual Studio Install and checking the following option:
Windows and Web Development / Universal Windows App Development Tools / Windows 10 SDK
It contains the standard C++ headers used in most applications and therefore it is often necessary to install it as well.
I had this issue under Windows 10 when using Visual Studio 2015 Professional, while Visual Studio 2015 Express worked! Under Windows 7, both Visual Studio versions used to work.
New projects created from the Visual Studio 2015 Professional IDE successfully compile, but CMake would fail to find the compiler reporting:
The C compiler identification is unknown
The CXX compiler identification is unknown
I upgraded CMake from 3.4.1 to 3.11.4, and now the problem is gone.
If you are on Visual Studio 2017 you need at least CMake 3.8!
I had a similar problem with the Visual Studio 2017 project generated through CMake. Some of the packages were missing while installing Visual Studio in Desktop development with C++. See snapshot:
Visual Studio 2017 Packages:
Also, upgrade CMake to the latest version.
Checking CMakeErrors.log in CMakeFiles returned:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140_xp\Toolset.targets(36,5): warning MSB8003: Could not find WindowsSdkDir_71A variable from the
registry. TargetFrameworkVersion or PlatformToolset may be set to an
invalid version number.
The error means that the build tools for XP (v140_xp) are not installed. To fix it I installed the proper feature in Visual Studio 2019 installer under Individual Components tab:
I was running old cmake version (i.e. 3.8) and I'm using visual studio 16 - 2019. After updating my cmake version, it did detect the compiler.
In my case there was an environment variable set which was the reason for this error.
The problem was solved after deleting cxx_flags from the environment variables.
I got this problem with CMake 3.12.1, after an update of Visual Studio 2017. I simply re-ran CMake and it worked.
In my case I could see in the CMakeError.log that CMake could not find the Windows SDK (MSB8003: Could not find WindowsSDKDir variable from the registry).
The version can be specified on the commandline on the first CMake run using:
-DCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION=
I got further after setting that, but I hit more issues later (so I assume my environment is messed up somehow), but maybe it will help someone with this issue.
A couple of tips:
Try to set the path manually by checking 'advanced' and modifying CMAKE_LINKER and CMAKE_MAKE_PROGRAM
Delete the cache - in the CMake with GUI go to:
File → Delete Cache.
My problem was a combination of previously stated: I have set the compiler version to 15 instead of 14 and when corrected, I had to delete the cache.
I also started the Visual Studio command prompt as an administrator and from there I ran the cmake-gui.exe
Then everything worked as it was supposed to.
In my case the issue was that the parent project, which is including googletest via
add_subdirectory(gtest_dir)
was defined as
PROJECT( projname CXX )
Somehow, CMake does not recognize
PROJECT(sub_project_name CXX C)
since the C compiler is not set in the parent.
I solved the issue by using
PROJECT( projname CXX C)
in my main CMakeLists.txt file.
This might be another solution for those with the latest Windows 10 creator version:
Stack Overflow post Fatal error LNK1104: cannot open file 'gdi32.lib'
None of the previous solutions worked for me. However I noticed that although I installed Visual Studio version 15 (not to be confused with Visual Studio 2015) the directory created on my computer was for Visual Studio 14.
When I specified Visual Studio 14 when I pressed the configuration button it worked.
i found this sollution at stackoverflow and i work for me although not working other sollutions
if you have a windows 10 OS, doing the following steps will fix the problem:
1) go to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
2) then copy RC.exe and RcDll from this file
3) go to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin and paste the two files you have copied into it.
thats all i hope it is helpful...
Look in the Cmakelists.txt if you find ARM you need to install C++ for ARM and as well vcvarsall.bat use for ARM bin folder.
It's these packages:
C++ Universal Windows Platform for ARM64 "Not Required"
Visual C++ Compilers and libraries for ARM "Not Required"
Visual C++ Compilers and libraries for ARM64 "Very Likely Required"
Required for finding Threads on ARM
enable_language(C)
enable_language(CXX)
Then the problems might disappear:
No CMAKE_C_COMPILER could be found.
No CMAKE_CXX_COMPILER could be found.
If above does not resolve your problem?
Optionally you can remove the options C and CXX in cmakelists.txt by setting # infront of where the enable_language(C) is. And avoid Android ARM processor compilation.
Resolved by adding the missing component
Modify->continue add as follow
I had a related problem: the Visual C++ generators were not even on the list when running cmake --help.
I ran where cmake in console and found that cygwin also provides its own cmake.exe file, which was being used. Changing the order of directories in PATH fixed the problem.
I had this issue with CMake GUI and the VS 21019 Community Edition. I think I may have installed CMake before Visual Studio - certainly after I updated CMake 3.15.2 to 3.15.3 the problem went away.
Check name folder too long or not.
This question is old, but none of the solutions here were working for me. I'm using Visual Studio 2019, and in my case, C++ compilation was working but just broke one day.
However, I noticed that there was an update ready to be installed in the Visual Studio Installer.
After installing that update, rebooting my computer, and relaunching Visual Studio, all of the C++ CMake problems disappeared. I'm not quite sure why this fixed it, and I can only speculate, but I can only assume that one of two things occurred. Either installing that update fixed a broken installation, or the update was quietly downloaded and prepared in the background, breaking things in the process.
I met the same issue in VSCode Cmake extension, i solve it by check following two options:
In the end, click [Scan for kits]
cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\g++.exe" -Hc:/code -Bc:/code/build -G "MinGW Makefiles"
I'm trying to automate the building process for a certain open source project. It will do an update on the SVN directory, use CMake to get a .sln file, and build that. I can successfully do this manually, and do svn and cmake from a batch script, but Now I need to build the solution.
A quick google search revealed:
devenv /build release /project <projname> <solutionfile>.sln
However, that uses the latest version of visual studio (Visual Studio Professional 2011), while the .sln file generated is for Visual C++ Express 2008. I have both versions installed on my computer. Is there a devenv I can use for Visual C++ Express 2008? Or is there a commandline argument to specify which version to use?
UPDATE
I tried using msbuild, but that didn't seem to like building .vcproj files directly, and I didn't want to build ALL the project files by having it build the .sln file. I ended up using this:
"C:\Program Files\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild.exe" <myproj>.vcproj "Release|Win32"
I think you are using the wrong tool to build this. Rather than trying to drive the IDE from the command line you should simply use msbuild.
msbuild.exe projectname.proj /property:Configuration=Release
In order to set your environment up for the specific version of MSVC you need to call the vcvar.bat file from that specific version. This will set up the necessary environment variables needed by the build tools.
For Visual Studio Express 2008 the IDE is called VCExpress.exe. Also you should probably specify the full path of the program when you have two versions installed:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\VCExpress.exe /build release /project <projname> <solutionfile>.sln