User forums > Help
Codeblocks and Visual studio 2017 and updates
pabristow:
Has anyone got Visual Studio 2017 Pro (or Community) to work with Codeblocks?
The Visual Studio (and tools and kits) directory structure has completely and radically changed for this version (and will keep changing rapidly with the very frequent MS update - Hurrah!)
The toolchain cl.exe etc are at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\bin\Hostx64\x64
and not in the folder /bin and things start OK
So I have put this at the 'root' toolchain folder and that seems to get started.
-------------- Build: vs2017_Release in hello_boost (compiler: Visual Studio 2017)---------------
cl.exe -Wall -fexceptions -O2 -DBOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE -Wall -II:\modular-boost -II:\modular-boost -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include" -I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt" -c J:\Cpp\Misc\hello_boost\hello_boost.cpp -o obj\Release\Misc\hello_boost\hello_boost.o
link.exe -L"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\lib" -o bin\Release\hello_boost.exe obj\Release\Misc\hello_boost\hello_boost.o -s "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\lib"
Microsoft (R) C/C++ Optimizing Compiler Version 19.13.26129 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release
cl : Command line warning D9002 : ignoring unknown option '-fexceptions'
hello_boost.cpp
but then produces zillions of errors
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\malloc.h(44): warning C4820: '_heapinfo': '4' bytes padding added after data member '_heapinfo::_useflag'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\vcruntime_exception.h(25): warning C4820: '__std_exception_data': '7' bytes padding added after data member '__std_exception_data::_DoFree'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\vcruntime_typeinfo.h(44): warning C4820: '__std_type_info_data': '7' bytes padding added after data member '__std_type_info_data::_DecoratedName'
I:\modular-boost\boost/config/stdlib/dinkumware.hpp(99): warning C4668: '_HAS_NAMESPACE' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\xlocinfo.h(59): warning C4820: '_Collvec': '4' bytes padding added after data member '_Collvec::_Page'
...
J:\Cpp\Misc\hello_boost\hello_boost.cpp : warning C4710: 'class std::basic_ostream<char,struct std::char_traits<char> > & __ptr64 __cdecl std::endl<char,struct std::char_traits<char> >(class std::basic_ostream<char,struct std::char_traits<char> > & __ptr64)': function not inlined
and finally the link fails thus
Microsoft (R) Incremental Linker Version 14.13.26129.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : warning LNK4044: unrecognized option '/LC:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\lib'; ignored
LINK : warning LNK4044: unrecognized option '/o'; ignored
LINK : warning LNK4044: unrecognized option '/s'; ignored
LINK : fatal error LNK1181: cannot open input file 'bin\Release\hello_boost.exe'
Should the setup file vsvarsall.bat be involved in the startup process?
Has anyone got this working properly (preferably with Boost and most important for me Boost.Test)?
Thanks for any hints and clues.
sodev:
Well, this happens when you use the GCC compiler settings with MSVC ;D. Use the Visual Studio 2010 compiler settings and adapt accordingly ;). Just a few days ago i posted the links to my 2015 setup here, you can take this as a guidance.
New Pagodi:
I've been trying to find a good solution for this too. What I've tried so far is to define 4 custom variables:
WINSDKROOT="C:\Program Files (x86)\Windows Kits\10"
WINSDKVERSION=10.0.16299.0 (or whatever kit is being used)
VCROOT=(whatever path visual c++ was installed to)
VCVERSION=14.13.26128 (or whatever the current version is)
Then I set the compiler and resource compiler search path to:
$(VCRoot)\$(VCVersion)\include
$(WinSDKRoot)\include\$(WinSDKVersion)\shared
$(WinSDKRoot)\include\$(WinSDKVersion)\ucrt
$(WinSDKRoot)\include\$(WinSDKVersion)\um
and the linker search path to:
$(VCRoot)\$(VCVersion)\lib\x64
$(WinSDKRoot)\lib\$(WinSDKVersion)\ucrt\x64
$(WinSDKRoot)\lib\$(WinSDKVersion)\um\x64
This way whenever the visual c++ kit gets updated, I only have to change the VCVERSION variable. Likewise, when a new SDK is released, I only have to change the WINSDKVERSION variable.
The problem is that this doesn't work for the toolchain executable paths if they have spaces in them. For example if I try to set the compilers installation directory to
--- Code: ---$(VCRoot)\$(VCVersion)\bin\Hostx64\x64
--- End code ---
where VCRoot is something like "C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC", the path for the compiler will get expanded to
--- Code: ---"C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC"\14.13.26128\bin\Hostx64\x64\cl.exe
--- End code ---
Apparently windows doesn't like having part of the full path quoted and the rest unquoted, so when codeblocks tries to invoke the compiler with that command, it fails. So the only thing I think I can do is reset the compilers's installation directory setting in addition to changing the VCVERSION variable everytime visual c is upgraded.
Does anybody have a better solution?
New Pagodi:
After trying a few more things, I've noticed that adding the following Aditional paths on the Toolchain executables page works:
C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC\$(VCVersion)\bin\Hostx64\x64
C:\Program Files (x86)\Windows Kits\10\bin\$(WinSDKVersion)\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
Codeblocks is able to find and invoke the compiler, resource compiler, and linker. And I think that way just changing VCVersion when visual c is updated and changing WinSDKVersion when the SDK is updated would be enough to keep both the includes/libs and the executables working. I'd rather keep those paths bottled up in the compiler variables like I can with the include/lib paths, but I guess it's better than nothing.
However there's still one problem. When codeblocks launches, it pops up a warning that it can't find the compiler in the executable search path. I assume this is either because the executables are not in a "bin" folder. They're in a folder named something like "...\bin\Hostx64\x64" or "...\bin\Hostx86\x64". Or it could be the variables in the paths aren't expanded in the check done when codeblocks starts.
Is there a way to stop this pop up warning when codeblocks starts?
BlueHazzard:
Ok, you have hit quite a lot bugs here. Lets sum them up:
1)
--- Code: ---$(VCRoot)\$(VCVersion)\bin\Hostx64\x64
--- End code ---
gets expanded into
--- Code: ---"C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC"\14.13.26128\bin\Hostx64\x64\cl.exe
--- End code ---
I hate windows for using spaces in important paths, but this is clearly a bug
2)
--- Quote ---However there's still one problem. When codeblocks launches, it pops up a warning that it can't find the compiler in the executable search path. I assume this is either because the executables are not in a "bin" folder. They're in a folder named something like "...\bin\Hostx64\x64" or "...\bin\Hostx86\x64". Or it could be the variables in the paths aren't expanded in the check done when codeblocks starts.
--- End quote ---
can you open two tickets on Source forge so they wont get lost?
i will try to look into them as soon as i find some time... (but there still needs to be a dev to review them and merge them into trunk)
Navigation
[0] Message Index
[#] Next page
Go to full version