Open LucaScheller opened 1 year ago
Hi @LucaScheller, I'm guessing that you had built once into a directory without OIIO enabled, then tried to build again into the same directory with OIIO enabled -- does that sound right? If so, you're running into a deficiency in the build script where it doesn't realize boost has to be rebuilt to include the boost::threads library that OIIO needs.
Could you try building with --openimageio
into a fresh directory, or adding --force BOOST
to your command line if you're building into the same directory?
Hey, sunyab thanks for the fast reply. If I build it on the first run with openimageio I get this error. log.txt
I'll try to build it again with the exact versions mentioed here: https://github.com/PixarAnimationStudios/USD/blob/release/VERSIONS.md
My current cmake and gcc versions are a lot newer, that might cause the problems
Ah yeah, from the log it looks like boost is hitting build errors when compiling boost::thread. I can't find any reports of this but I wonder if boost 1.70 has problems with gcc 12. You could try changing the version of boost getting used in build_usd.py to something later and see if that helps?
OIIO CI tests against gcc12, so that should be fine from the OIIO perspective. Also, OIIO can use any boost from 1.53 or so up through the very latest (its use of boost is extremely minimal, and I am aiming to eventually wean it off the last few things, but we're not quite there yet).
Looks from the logs like your boost build itself is failing, maybe something in the old 1.70 boost is not making gcc12 happy. The oiio build log at the top of this thread indicates that oiio is finding boost 1.70, but that in particular it does not appear to contain the thread module as expected. (If you're using a pre-built boost from a package installer, sometimes boost can be divided up and you may need to request boost-threads or boost-all explicitly?)
My take is that vfx platform may say boost 1.70 or whatever, but actually very little changes from one boost version to the next (other than adding new libraries) and most of their modules are header only, so there is usually no real harm in having a newer boost than they expect. If you need a newer boost because you simply must use gcc 12, that's probably fine (note: vfx platform says it tries to be compatible with gcc 9 for 2022, gcc 11 for 2023, which nobody is using yet, so insisting on gcc12 may come back to haunt you as you build other packages that are trying to fit into VFX Platform, it might all work, or you might find yourself trying to swim upstream).
It also may be that the errors gcc is complaining about when building boost are actually just escalated warnings that can be individually disabled. I'm no expert in building boost, but maybe their build scripts have some kind of "please don't treat warnings as full errors" option that can be used to just force it to build despite the problems?
Aside: Does USD's CI test against gcc11 and gcc12? I recommend it. Even if nobody is using them in the studios today, it's usually better to get all those new compiler warnings cleaned up long before people are relying on it.
Hey @lgritz / @sunyab, thanks for your replies!
I'm using the build script (build_scripts/build_usd.py) shipped with the repo that downloads and builds with boost 1.70.0. It builds boost without errors when not building with oiio. According to the buildscript the threading modules are being built.
If I change the boost version to 1.81.0 (current latest), it builds oiio successfully, but fails to build Usd (I get the attached error log). With version 1.74.0 it builds successfully :tada: (Not sure if it is worth doing a PR for this, as I'm not sticking to the VFX Ref Platform)
When using the aswf/ci-base:2020.9 docker image, it also builds without problems. If I run into more problems though (when e.g. building with OCIO etc), I think I'll just compile via docker then, to avoid the headaches :)
Thanks again for your help so far :)
| Does USD's CI test against gcc11 and gcc12? Not sure if this is being done, sounds like a thing worth doing though
The patch suggested by the compiler in the log.txt might address the 1.81.0 problem and would be harmless otherwise, if you're motivated to give it a shot.
In file included from /mnt/data/SOFTWARE/USD___Latest___x64___linux/USD/pxr/base/gf/wrapPlane.cpp:26:
/mnt/data/SOFTWARE/USD___Latest___x64___linux/USD/pxr/base/gf/plane.h:207:36: error: ‘vector’ in namespace ‘std’ does not name a template type
207 | bool GfFitPlaneToPoints(const std::vector<GfVec3d>& points, GfPlane* fitPlane);
| ^~~~~~
/mnt/data/SOFTWARE/USD___Latest___x64___linux/USD/pxr/base/gf/plane.h:33:1: note: ‘std::vector’ is defined in header ‘<vector>’; did you forget to ‘#include <vector>’?
32 | #include "pxr/base/gf/api.h"
+++ |+#include <vector>
33 |
Filed as internal issue #USD-7870
Description of Issue
Hey, I'm currently trying to build Usd via the build_script.py and it fails when building with openimagio.
Running this:
python USD/build_scripts/build_usd.py USD/build
works fine (except also having this issue in the UsdView: https://github.com/PixarAnimationStudios/USD/issues/2153)Running this:
python USD/build_scripts/build_usd.py USD/build --openimageio
fails with the following error:It seems to not find the boost install that the previous build step created. I've tried adding it via
on line 1332 in build_script.py, but with no success.
System Information (OS, Hardware)
OS: Fedora 37 CPU: AMD Ryzen™ 9 6900HX Python Version: Python 3.9.16
Has anyone had this issue so far? Any help would be highly appreciated :) Cheers, Luca