# Windows build error with cmb-superbuild:release VS2017
**URL:** https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359
**Category:** Build & Install
**Created:** [December 6, 2019, 10:05pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359 "2019-12-06T22:05:19Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 6, 2019, 10:05pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/1 "2019-12-06T22:05:19Z")
Using:
- current release branch (b6f35848 Thu 05-Dec-2019)
- default cmake values except `USE_SYSTEM_qt5`, which is set to [qt.io](http://qt.io) 5.12.6 binaries
There are 2 separate errors in the configure-remus step.
1. Unable to find the boost components. From the command prompt (console):
```
-- Found Threads: TRUE
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find Boost (missing: thread chrono filesystem system date_time)
(found suitable version "1.66.0", minimum required is "1.48.0")
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2165 (find_package_handle_standard_args)
CMakeLists.txt:75 (find_package)
-- Configuring incomplete, errors occurred!
```
2. The remus CMakeError.log file is also non-empty with a different error message:
```
Determining if the include file pthread.h exists failed with the following output:
Change Dir: C:/Users/IEUser/Documents/build/release-superbuild/superbuild/remus/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/Users/IEUser/bin/ninja.exe cmTC_9cf5d && [1/2] Building C object CMakeFiles\cmTC_9cf5d.dir\CheckIncludeFile.c.obj
FAILED: CMakeFiles/cmTC_9cf5d.dir/CheckIncludeFile.c.obj
C:\PROGRA~2\MICROS~2\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /FoCMakeFiles\cmTC_9cf5d.dir\CheckIncludeFile.c.obj /FdCMakeFiles\cmTC_9cf5d.dir\ /FS -c CheckIncludeFile.c
CheckIncludeFile.c(1): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
ninja: build stopped: subcommand failed.
```
---
### Author:  [@ben.boeckel](https://discourse.kitware.com/u/ben.boeckel)
#### Post date: [December 10, 2019, 8:09pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/2 "2019-12-10T20:09:44Z")
The error output is a red herring; all `try_compile` code goes there. That’s the output saying "`pthread.h` is not present" which is OK on Windows.
The first means that FindBoost isn’t finding the libraries. There are some debugging options to get FindBoost to be more chatty. What output do you get if you add those flags?
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 10, 2019, 10:35pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/3 "2019-12-10T22:35:33Z")
The problem is the VC toolset. I’ll paste some of the console messages from configuring remus with Boost\_DEBUG (cannot upload text file to discourse?), but the short version is that FindBoost when configuring remus is looking for vc140 or vc141 boost libs, but VS2017 is generating vc150 boost libs.
- I am using Visual Studio Community 2017, Version 15.9.7, which I _think_ is the latest.
- CMake reports the MSCV\_VERSION as 1916, which should generate vc141 files according to CMake docs.
- I see there was a commit on common-superbuild:master to update win32/boost.cmake Nov 11 ( [link](https://gitlab.kitware.com/paraview/common-superbuild/commit/e03213803382c09ac97925f54233fa6f38714145) ) for VS 2019. That commit still doesn’t look consistent with the CMake page for MSVC\_VERSION, so I am going to addlib my own mod and try that next.
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 10, 2019, 11:06pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/4 "2019-12-10T23:06:00Z")
This patch to the common-superbuild used by cmb-superbuild:release works for me, at least in terms of configuring remus.
```
diff --git a/projects/win32/boost.cmake b/projects/win32/boost.cmake
index ecccb15..a61b6f2 100644
--- a/projects/win32/boost.cmake
+++ b/projects/win32/boost.cmake
@@ -13,9 +13,9 @@ elseif (NOT MSVC_VERSION VERSION_GREATER 1800)
set(msvc_ver 12.0)
elseif (NOT MSVC_VERSION VERSION_GREATER 1900)
set(msvc_ver 14.0)
-elseif (NOT MSVC_VERSION VERSION_GREATER 1910)
- set(msvc_ver 14.1)
elseif (NOT MSVC_VERSION VERSION_GREATER 1920)
+ set(msvc_ver 14.1)
+elseif (NOT MSVC_VERSION VERSION_GREATER 1930)
set(msvc_ver 15.0)
else ()
message(FATAL_ERROR "Unrecognized MSVC version: ${MSVC_VERSION}")
```
---
### Author:  [@aron.helser](https://discourse.kitware.com/u/aron.helser)
#### Post date: [December 11, 2019, 2:08pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/5 "2019-12-11T14:08:05Z")
I was sure I had seen exactly that modification go in already - I wonder why it got missed?
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 11, 2019, 3:53pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/6 "2019-12-11T15:53:38Z")
Moving on from boost.cmake, the next build error is a problem finding kernel32.lib:
```
[1/45] Linking CXX shared library superbuild\cxx11_check.dll
FAILED: superbuild/cxx11_check.dll superbuild/cxx11_check.lib
cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=superbuild\CMakeFiles\cxx11_check.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo superbuild\CMakeFiles\cxx11_check.dir\projects\scripts\cxx11.cxx.obj /out:superbuild\cxx11_check.dll /implib:superbuild\cxx11_check.lib /pdb:superbuild\cxx11_check.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK: command "C:\PROGRA~2\MICROS~2\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo superbuild\CMakeFiles\cxx11_check.dir\projects\scripts\cxx11.cxx.obj /out:superbuild\cxx11_check.dll /implib:superbuild\cxx11_check.lib /pdb:superbuild\cxx11_check.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:superbuild\cxx11_check.dll.manifest" failed (exit code 1181) with the following output:
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib'
```
Is there an sdk or something I need to install??
---
### Author:  [@ben.boeckel](https://discourse.kitware.com/u/ben.boeckel)
#### Post date: [December 11, 2019, 6:42pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/7 "2019-12-11T18:42:16Z")
> looking for vc140 or vc141 boost libs, but VS2017 is generating vc150 boost libs.
Oh, this is a thing to fix in `superbuild/projects/win32/boost.cmake`. Thought I had that fixed though…
---
### Author:  [@ben.boeckel](https://discourse.kitware.com/u/ben.boeckel)
#### Post date: [December 11, 2019, 6:43pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/8 "2019-12-11T18:43:28Z")
> [@johnt](#):
>
> cmb-superbuild:release
Ah, that’d be why 🙂 .
> [@johnt](#):
>
> Is there an sdk or something I need to install??
That is certainly weird. I’ll look at my docker history to see if I ran some other env settings first.
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 11, 2019, 7:45pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/9 "2019-12-11T19:45:01Z")
My apologies to everyone tracking this. I had _completely_ forgotten about the “command line length” problem on windows, so I had to restart from scratch in a new directory with a darn-short path (I used C:\cmb\bld).
- The good news is that, **YES** , cmb:release builds in the new folder. So either the longer paths were screwing things up or maybe I needed to do a completely clean build (?)
- Just so I don’t forget, this still requires my one-line mod to the win32/boost.cmake file in common-superbuild (setting msvc\_ver to 14.1 for MSCV\_VERSION \< 1920).
- I’m not completely done, however. Packaging fails to install the cmbPostProcessingPlugin because the Qt libs cannot be found. I’ll paste the console message below. I have some recollection this was previously fixed for Linux and/or macOS, so maybe there is an easy fix.
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 12, 2019, 10:13pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/10 "2019-12-12T22:13:21Z")
Looking at why fixup\_bundle fails for the cmbPostProcessing plugin, I can see that the cmake\_install.cmake file generated at cpack/modelbuilder/ZIP/build includes the Qt path for modelbuilder but not cmbPostProcessingPlugin. @ben.boeckel can you tell me where that file gets generated?
---
### Author:  [@ben.boeckel](https://discourse.kitware.com/u/ben.boeckel)
#### Post date: [December 13, 2019, 1:47pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/11 "2019-12-13T13:47:55Z")
There’s a `library_paths` variable in `cmb.bundle.windows.cmake` that is probably missing in the plugin call(s).
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [December 13, 2019, 8:36pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/12 "2019-12-13T20:36:42Z")
When the packaging test gets to cmb.bundle.windows.cmake, the library paths passed in to superbuild\_windows\_install\_plugin() look correct to me, but these paths don’t show up in what gets passed to fixup\_bundle. So I am trying to figure out where the disconnect is.
FYI adding some printf’s to cmb.bundle.windows.cmake (staring at line 80):
```
110: CHECKPOINT 100
110: cmb_plugins_cmb cmbPostProcessingModePlugin
110: library_paths: lib;bin;C:/Qt/5.12.6/msvc2017_64/lib/cmake/Qt5/../../../bin
110: plugin_library_paths lib;bin;C:/Qt/5.12.6/msvc2017_64/lib/cmake/Qt5/../../../bin
110: CHECKPOINT 150
```
---
### Author:  [@ben.boeckel](https://discourse.kitware.com/u/ben.boeckel)
#### Post date: [December 18, 2019, 7:05pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/13 "2019-12-18T19:05:03Z")
Oh, the plugin is always-static now. We should exclude it from packaging.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [January 10, 2020, 9:06pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/14 "2020-01-10T21:06:36Z")
> [@johnt](#):
>
> Just so I don’t forget, this still requires my one-line mod to the win32/boost.cmake file in common-superbuild (setting msvc\_ver to 14.1 for MSCV\_VERSION \< 1920).
I believe [this common-superbuild MR](https://gitlab.kitware.com/paraview/common-superbuild/merge_requests/335) fixes your issue.
Also, we have found that this:
```cmake
CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc
```
is necessary in the superbuild’s top-level CMakeCache.txt file to prevent multiple build issues. (The `/EHsc` prevents errors related to boost::exception, the `/DWIN32` is required or MOAB will complain that `strcasecmp()` is missing.)
``We need to commit superbuild changes so Windows builds work for everyone without resorting to docker images or research on the Discourse forum. ``
---
### Author:  [@aron.helser](https://discourse.kitware.com/u/aron.helser)
#### Post date: [January 10, 2020, 9:16pm UTC](https://discourse.kitware.com/t/windows-build-error-with-cmb-superbuild-release-vs2017/359/15 "2020-01-10T21:16:28Z")
I believe these settings were done for me automatically - could be Sam missed them because of running cmake once in the git bash shell.