Windows build error with cmb-superbuild:release VS2017

Using:

  • current release branch (b6f35848 Thu 05-Dec-2019)
  • default cmake values except USE_SYSTEM_qt5, which is set to 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.

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?

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 ) 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.

    – [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2044 ] Searching for SYSTEM_LIBRARY_RELEASE: boost_system-vc141-mt-x64-1_66;boost_system-vc141-mt-x64;boost_system-vc141-mt;boost_system-vc140-mt-x64-1_66;boost_system-vc140-mt-x64;boost_system-vc140-mt;boost_system-mt-x64-1_66;boost_system-mt-x64;boost_system-mt;boost_system-mt;boost_system
    – [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2099 ] Searching for SYSTEM_LIBRARY_DEBUG: boost_system-vc141-mt-gd-x64-1_66;boost_system-vc141-mt-gd-x64;boost_system-vc141-mt-gd;boost_system-vc140-mt-gd-x64-1_66;boost_system-vc140-mt-gd-x64;boost_system-vc140-mt-gd;boost_system-mt-gd-x64-1_66;boost_system-mt-gd-x64;boost_system-mt-gd;boost_system-mt;boost_system
    – [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2044 ] Searching for DATE_TIME_LIBRARY_RELEASE: boost_date_time-vc141-mt-x64-1_66;boost_date_time-vc141-mt-x64;boost_date_time-vc141-mt;boost_date_time-vc140-mt-x64-1_66;boost_date_time-vc140-mt-x64;boost_date_time-vc140-mt;boost_date_time-mt-x64-1_66;boost_date_time-mt-x64;boost_date_time-mt;boost_date_time-mt;boost_date_time
    – [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2099 ] Searching for DATE_TIME_LIBRARY_DEBUG: boost_date_time-vc141-mt-gd-x64-1_66;boost_date_time-vc141-mt-gd-x64;boost_date_time-vc141-mt-gd;boost_date_time-vc140-mt-gd-x64-1_66;boost_date_time-vc140-mt-gd-x64;boost_date_time-vc140-mt-gd;boost_date_time-mt-gd-x64-1_66;boost_date_time-mt-gd-x64;boost_date_time-mt-gd;boost_date_time-mt;boost_date_time
    – [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2044 ] Searching for ATOMIC_LIBRARY_RELEASE: boost_atomic-vc141-mt-x64-1_66;boost_atomic-vc141-mt-x64;boost_atomic-vc141-mt;boost_atomic-vc140-mt-x64-1_66;boost_atomic-vc140-mt-x64;boost_atomic-vc140-mt;boost_atomic-mt-x64-1_66;boost_atomic-mt-x64;boost_atomic-mt;boost_atomic-mt;boost_atomic
    – [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2099 ] Searching for ATOMIC_LIBRARY_DEBUG: boost_atomic-vc141-mt-gd-x64-1_66;boost_atomic-vc141-mt-gd-x64;boost_atomic-vc141-mt-gd;boost_atomic-vc140-mt-gd-x64-1_66;boost_atomic-vc140-mt-gd-x64;boost_atomic-vc140-mt-gd;boost_atomic-mt-gd-x64-1_66;boost_atomic-mt-gd-x64;boost_atomic-mt-gd;boost_atomic-mt;boost_atomic
    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)

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}")

I was sure I had seen exactly that modification go in already - I wonder why it got missed?

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??

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…

Ah, that’d be why :slight_smile: .

That is certainly weird. I’ll look at my docker history to see if I ran some other env settings first.

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.

    CMake Error at C:/cmb/bld/cpack/modelbuilder/ZIP/build/cmake_install.cmake:94 (message):
    110: Failed to install cmbPostProcessingModePlugin.dll:
    110:
    110: Traceback (most recent call last):
    110:
    110: File “C:/cmb/src/superbuild/cmake/scripts/fixup_bundle.windows.py”, line 440, in
    110: main(sys.argv[1:])
    110: File “C:/cmb/src/superbuild/cmake/scripts/fixup_bundle.windows.py”, line 432, in main
    110: _install_binary(main_exe, is_excluded, bundle_dest, libdir, installed, manifest, dry_run=opts.dry_run)
    110: File “C:/cmb/src/superbuild/cmake/scripts/fixup_bundle.windows.py”, line 332, in _install_binary
    110: deps = binary.dependencies.values()
    110: File “C:/cmb/src/superbuild/cmake/scripts/fixup_bundle.windows.py”, line 155, in dependencies
    110: deplib = Library.from_reference(dep, self)
    110: File “C:/cmb/src/superbuild/cmake/scripts/fixup_bundle.windows.py”, line 202, in from_reference
    110: raise RuntimeError(‘Unable to find the %s library from %s: %s’ % (ref, loader.path, ', '.join(paths)))
    110:
    110: RuntimeError: Unable to find the Qt5Widgets.dll library from
    110: C:\cmb\bld\install\bin\cmbPostProcessingModePlugin.dll:
    110: C:\cmb\bld\install\bin, C:\Program Files (x86)\Microsoft Visual
    110: Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64, C:\Program
    110: Files (x86)\Microsoft Visual
    110: Studio\2017\Community\Common7\IDE\VC\VCPackages, C:\Program Files
    110: (x86)\Microsoft Visual
    110: Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow,
    110: C:\Program Files (x86)\Microsoft Visual
    110: Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
    110: Explorer, C:\Program Files (x86)\Microsoft Visual
    110: Studio\2017\Community\MSBuild\15.0\bin\Roslyn, C:\Program Files
    110: (x86)\Microsoft Visual Studio\2017\Community\Team Tools\Performance
    110: Tools\x64, C:\Program Files (x86)\Microsoft Visual
    110: Studio\2017\Community\Team Tools\Performance Tools, C:\Program Files
    110: (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\x64,
    110: C:\Program Files (x86)\Microsoft Visual
    110: Studio\Shared\Common\VSPerfCollectionTools, C:\Program Files (x86)\Windows
    110: Kits\10\bin\10.0.17763.0\x64, C:\Program Files (x86)\Windows
    110: Kits\10\bin\x64, C:\Program Files (x86)\Microsoft Visual
    110: Studio\2017\Community\MSBuild\15.0\bin,
    110: C:\Windows\Microsoft.NET\Framework64\v4.0.30319, C:\Program Files
    110: (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE, C:\Program Files
    110: (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools,
    110: C:\ProgramData\DockerDesktop\version-bin, C:\Program
    110: Files\Docker\Docker\Resources\bin, C:\Windows\system32, C:\Windows,
    110: C:\Windows\System32\Wbem, C:\Windows\System32\WindowsPowerShell\v1.0,
    110: C:\Windows\System32\OpenSSH, C:\ProgramData\chocolatey\bin, C:\Program
    110: Files\Puppet Labs\Puppet\bin, C:\Program Files\Git\cmd,
    110: C:\Users\IEUser\AppData\Local\Microsoft\WindowsApps, C:\Program
    110: Files\CMake\bin, C:\Users\IEUser\bin, ,
    110: C:\Users\IEUser\AppData\Local\Programs\Microsoft VS Code\bin, C:\Program
    110: Files (x86)\Microsoft Visual
    110: Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin,
    110: C:\Program Files (x86)\Microsoft Visual
    110: Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja,
    110: C:/cmb/bld/install/bin, C:/cmb/bld/install/lib,
    110: C:/cmb/bld/install/x64/vc14/bin

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?

There’s a library_paths variable in cmb.bundle.windows.cmake that is probably missing in the plugin call(s).

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

Oh, the plugin is always-static now. We should exclude it from packaging.

I believe this common-superbuild MR fixes your issue.

Also, we have found that this:

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.)

<rant>We need to commit superbuild changes so Windows builds work for everyone without resorting to docker images or research on the Discourse forum. </rant>

I believe these settings were done for me automatically - could be Sam missed them because of running cmake once in the git bash shell.

Privacy Notice