Boost 1.61.0 build fails on Windows 10 16299.248

rskryptik61636 commented 6 years ago

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

Clone the master branch of USD.
Open an MSVC 14.0 command prompt and add Python, CMake, pyside-uic and NASM to the path.
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 commented 6 years ago

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

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 3a387cd416ea1c5c5cdadd19a992e9ab26916b6b, which is currently in the dev branch.
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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

Filed as internal issue #157953.

rskryptik61636 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 1 year ago

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?

PixarAnimationStudios / OpenUSD