Page MenuHomePhabricator

Make Boost build robust
Closed, ResolvedPublic

Description

Building Boost fails with the current superbuild using Visual Studio 2017. I've tried Visual Studio 15.3 (Not completely sure, might have been 15.2) and updated also to 15.6.5. Performing a superbuild always leads to the Boost-Building Step exiting with Code 2, and therefore MITK isn't build. According to Bootstrap, the problem is a linking conflict:

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.6.5
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
###
### Using 'vc141' toolset.
###
command.c
compile.c
constants.c
debug.c
execcmd.c
execnt.c
filent.c
frames.c
function.c
glob.c
hash.c
hdrmacro.c
headers.c
jam.c
jambase.c
jamgram.c
lists.c
make.c
make1.c
object.c
Generating Code...
Compiling...
option.c
output.c
parse.c
pathnt.c
pathsys.c
regexp.c
rules.c
scan.c
search.c
subst.c
timestamp.c
variable.c
modules.c
strings.c
filesys.c
builtins.c
md5.c
class.c
cwd.c
w32_getreg.c
Generating Code...
Compiling...
native.c
set.c
path.c
regex.c
property-set.c
sequence.c
order.c
Generating Code...
libucrtd.lib(exit.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86'

Event Timeline

kislinsk added a subscriber: kislinsk.

Boost is set in your case to be built in 32 bits even though it should be 64 bits. It's probably due to a compiler update without cleaning the superbuild. You can try to build boost again after deleting all boost stuff in the ep folder, or do a fresh superbuild during MiSi.

Strange. The problems is still there, although the report has been closed. So we will have to try another solution...

What I tried/know so far

  • Made several clean superbuilds, all failed.
  • Superbuilds fail regardless if build as Release / Debug or Release+Debug
  • Superbuild fails if build as x86
  • Made sure that the project is actually a x64 by default.
  • Changed CMake to always build boost as x86 (As it is usually build as x64 for a x64 Version of MITK)
  • Repaired my VS Installation
    • This did the trick for Jasmin, who had the same problem yesterday when building a complete new superbuild after some months, but not for me.
  • Updated my VS installation from 15.2 to 15.6.5

I am now trying to uninstall VS completely and reinstall it again. Hope that solves the problem.

Had the same problem: T24361
The problem disappeared mysteriously after some time...

I've tried to solve the problem by deinstalling Visual Studio and all related tools and reinstalling everything.

First try:

  1. Deinstalled everything (VS, VS Components, old VS remains)
  2. Restarted Computer
  3. Reinstalled Visual Studio: C++ Components, No Plugins, Language Packages Englisch, German. Activated Englisch.
  4. Restarted Computer
  5. Tried to build the Superbuild in Batch Mode with Release and Debug in a new folder.
  6. Failed.
  7. Removed Anaconda from %PATH%
  8. Tried to build Superbuild in Batch mode with release and debug in a new folder.
  9. Failed. (Now with additional errors beside boost)

Second try:

  1. Deinstalled VS and Restarted Computer
  2. Installed VS Studio. See screenshot for selected Modules / Options.
    Working_Configuration.PNG (729×364 px, 40 KB)
  3. Tried to build the Superbuild in Batch mode with Release.
  4. Seems to work in genereal. I now got only an error while downloading MITK-Data (RPC failed; result=22, HTTP code 502), didn't looked into it so far.

I don't know what did the trick so far. And I don't know if the solution will keep working, as I already though once that the build is working, but it changed with the second build...

Since Boost seems to be a source of mysterious fails in the Superbuild with VS 2017, I will try to dig a bit deeper into this. (Similar errors were reported at least by @metzger and @hentsch). While they somehow dissapeared after some time, they are still anyoing and we should investigate it definitly.

My current guess is a system configuration error, but I am not sure about it. I hope to get more insights so that we can give a "Resolving guideline".

As a starting point, those are points I've changed between the working and non-working approaches (At least as far as i am aware of them):

  • Fail: Installed VS with German and Englisch, activated Englisch. Working: German only.
  • Fail: Anaconda3 in the %PATH% Variable during VS Installation. Working: No Anaconda3
  • Fail: Build in Batch Mode with Debug and Release. Working: Build with Release only.
  • Fail: Different selection of modules in VS Installation (Tried several configurations). Working: See screenshot of previous post.

What i am pretty sure is not the cause of the problem so far:

  • CMake installation: Didn't changed it between working and non-working runs.
  • Different Visual Studio Plugins. Had no plugins installed, both in the working and non-working runs.
  • Building in old Superbuild Directories. This might cause problems, but is not the root of this problem.

I will test some ideas and will extend both lists if I'll find something else / remember more.

Any suggestions so far what else should be tested?

Tried to change following:

  • installed english language pack, selected the english interface
  • installed two Extensions: "Productivity Power Tools", "Trailing Whitespace Visualizer", and "Clang Power Tools"
  • Builded Superbuild in a new directory:
    • BatchBuild Debug and Release
    • Started VS from CMake (Open Project)
    • Additional activate beside standard: SWIG, Vigra, MatchPoint

Build still running...

While my build is still running, I gathered following Information:
@hentsch excluded the following reasons on his computer:

  • No Windows Update
  • No additional VS update / Repair
  • Had unsuccessfully tried a computer restart before.

@hentsch has Python, although not Anaconda. @metzger has no Python. So I guess that is also not source of the problem.

Ok. seems that those were not the critical points. Building is still possible.
I'm going to close this bug, but we should keep looking on.

My best advice for everybody with the same problem so far: Deinstall Visual Studio, Restart, Install with the Options above, Restart again.

goetzm claimed this task.

For me,

  • it didn't worked with BatchBuild (Debug and Release),
  • but with repeated subsequent builds (first Release, then Debug)

Tested also clean build. There, it didn't work (libucrtd.lib(exit.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86')

This here

[vcvarsall.bat] Environment initialized for: 'x86'
###
### Using 'vc141' toolset.
###

Should tell us which batch file sets the Visual Studio environment. Does it read x64 for your working builds?

No, bootstrap.log always read
[vcvarsall.bat] Environment initialized for: 'x86' regardless if boost was built or not.

goetzm added a subscriber: holzwart.

Reopened, error reported by @holzwart

I use:
VS 15.6.5
Cmake 3.11.0
Git 2.12.2.windows.2

I did a clean superbuild and after adding OpenCV the error appeared.

This comment was removed by holzwart.

It works now after clean build and cloneing the repository again.

I suggest to re-open this task only if someone is able to reproduce this constantly. Otherwise this will be an open task for the next 10 years. :-)

Still relevant. Using VS 2017 15.5.4
Very annoying: as we use header-only boost libraries in the default MITK build, the boost step just prevents the Superbuild from being successful without reason

kislinsk triaged this task as Normal priority.Oct 5 2018, 9:17 AM
kislinsk renamed this task from Boost Build fails for current Superbuild using Visual Studio 2017 to Make Boost build robust.Oct 12 2018, 2:04 PM
kislinsk claimed this task.
kislinsk removed subscribers: goch, MITK.

I'll make an internal survey to find out in which configurations they are problems and in which Boost builds fine.

Probably found the origin of issue. We're calling bootstrap.bat on Windows and bootstrap.sh on other platforms. The latter script has lots of parameters like --with-toolset=..., while the former script just knows a single parameter like vc141. However, we currently assume that the former script would also understand --with-toolset=v141. The script doesn't know how to handle this and falls back to something else.