Boost 1.61.0 build fails on Windows 10 16299.248

[rskryptik61636]

Description of Issue

The Boost 1.61.0 build fails with the following error message: "ERROR: Failed to run 'b2 --prefix="C:\Program Files\USD" --build-dir="C:\Program Files\USD\build" -j8 address-model=64 link=shared runtime-link=shared threading=multi variant=release --with-atomic --with-date_time --with-filesystem --with-program_options --with-python --with-regex --with-system --with-thread toolset=msvc-14.0 install'
See C:\Program Files\USD\src\boost_1_61_0\log.txt for more details."

Log file attached here: log.txt

Steps to Reproduce

1. Clone the master branch of USD.
2. Open an MSVC 14.0 command prompt and add Python, CMake, pyside-uic and NASM to the path.
3. Run: "python USD\build_scripts\build_usd.py --no-python"C:\Program Files\USD""

System Information (OS, Hardware)

OS: Windows 10 16299.248
CPU: Intel Core i7-4770k
GPU: NVIDIA GTX 1060
RAM: 20 GB DDR3

Package Versions

Python: 2.7.11
CMake: 3.3.1
MSVC: 14.0 (VS 2015)

Build Flags

No additional build flags specified.

[sunyab]

It looks like the boost build is failing when trying to link Python for boost::python. There's a couple of things here:

1. You've specified --no-python, but the build script is still trying to build boost::python. This was an oversight in the build script and was fixed in commit 3a387cd, which is currently in the dev branch.

2. If you had wanted to build with Python support, this line in your log:

c:\Python27\libs\python27.lib : warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64'

makes me suspect you have the 32-bit version of Python installed instead of the x64 one, which would cause that error.

Hope that helps!

[rskryptik61636]

Nice, 64-bit Python did the trick. Could the README be updated to specify 64-bit Python? It makes sense that the 64-bit version is the one that needs to used since build_usd.py is being run from a 64-bit MSVC command prompt but it would help if that was explicitly called out in the README.

Boost builds now and it gets further but fails on OpenImageIO (log file: log.txt)

It looks like it can't find the boost headers. I tried adding BOOST_ROOT and BOOST_INCLUDEDIR to the OIIO CMake flags by adding them to the extraArgs array under the InstallOpenImageIO function but that didn't seem to work. Is there something else I should be doing?

[meshula]

I build OIIO from a batch file. I had to specify a lot of things. I have a variable called %current%, and have built everything into a directory %current%\local.

cmake -G "Visual Studio 15 2017 Win64"^
    -DCMAKE_PREFIX_PATH="%current%\local"^
    -DCMAKE_INSTALL_PREFIX="%current%\local" ^
    -DCMAKE_CXX_COMPILER_WORKS=1 ^
    -DOPENEXR_CUSTOM_INCLUDE_DIR:STRING="%current%\local\include" ^
    -DOPENEXR_CUSTOM_LIB_DIR="%current%\local\lib" ^
    -DBOOST_ROOT="%current%\local" ^
    -DBOOST_LIBRARYDIR="%current%\local\lib" ^
    -DBoost_USE_STATIC_LIBS:INT=0 ^
    -DBoost_LIBRARY_DIR_RELEASE="%current%\local\lib" ^
    -DBoost_LIBRARY_DIR_DEBUG="%current%\local\lib" ^
    -DOCIO_PATH="%current%\local" ^
    -DPTEX_LOCATION="%current%\local" ^
    -DUSE_PTEX=0 ^
    ..\..\oiio

[sunyab]

@rskryptik61636 - yep, we'll add a little note to the README mentioning that a 64-bit compiler and 64-bit versions of all dependencies are needed.

Regarding the OpenImageIO build, I have not run into that issue before so I'm not sure what's going on. Do you have another installation of boost somewhere in your %PATH%? If you could post the CMakeCache.txt from the OIIO build directory we might be able to see what the build is looking at. You could also add the option "-DVERBOSE=ON" to the extraArgs list and re-run the build to get more information out of the OIIO build.

[jtran56]

Filed as internal issue #157953.

[rskryptik61636]

OpenImageIO builds after adding both BOOST_ROOT and BOOST_INCLUDEDIR to extraArgs. It also initially found some version of libpng in a directory on my PATH and linked against that by mistake but I got around it by removing that directory from the PATH. The script completes successfully now and the USD solution has been generated.

Is there a way to make the script look for all dependencies under the target dir itself instead of on the PATH first?

[meshula]

There is. It’s worth investigating. It’s not as “simple” as the documentation makes it appear, as there are many search and cache heuristics in cmake itself. I keep thinking I have figured it out, and discover more loopholes.

https://cmake.org/cmake/help/v3.0/command/find_library.html

[sunyab]

This sounds similar to issue #256. It would be interesting to try the suggestion in that issue and have the build script prepend paths to the built dependencies in %PATH%.

[sunyab]

Had some time to look into this and other build issues last night. One possible reason why OpenImageIO wasn't able to find boost is that the version of cmake wasn't new enough. CMake only added support for boost 1.61.0 starting with version 3.5.0; prior versions wouldn't know where to look unless they were explicitly specified with the BOOST_* CMake variables.

This may also explain other bug reports where boost is being picked up from %PATH%. If someone is using a version of cmake < 3.5.0 and has a version of boost < 1.61 on their %PATH%, the version of boost that build_usd.py builds will be ignored and the version from %PATH% will be used instead.

I'm still not sure why libpng would've been picked up from %PATH% though.

[meshula]

Currently the minimum USD supported version of boost on msvc is 1.70. I'm wondering if there are still issues to resolve here, or if we can close this issue?