blender failed to build from source in Fedora rawhide/f42 https://koji.fedoraproject.org/koji/taskinfo?taskID=127935851 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild Please fix blender at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, blender will be orphaned. Before branching of Fedora 43, blender will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 2068385 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 2068386 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 2068387 [details] state.log
*** Bug 2339546 has been marked as a duplicate of this bug. ***
FAILED: intern/cycles/scene/CMakeFiles/cycles_scene.dir/image_vdb.cpp.o /usr/bin/ccache /usr/lib64/ccache/g++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_LOCALE_DYN_LINK -DBOOST_LOCALE_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DBOOST_WAVE_DYN_LINK -DBOOST_WAVE_NO_LIB -DCCL_NAMESPACE_BEGIN="namespace ccl {" -DCCL_NAMESPACE_END=} -DCYCLES_GFLAGS_NAMESPACE=gflags -DGOOGLE_GLOG_DLL_DECL="" -DHAVE_EXECINFO_H -DNDEBUG -DTBB_SUPPRESS_DEPRECATED_MESSAGES=1 -DWITH_ALEMBIC -DWITH_ASSERT_ABORT -DWITH_BLENDER_GUARDEDALLOC -DWITH_CUDA -DWITH_CUDA_DYNLOAD -DWITH_CYCLES_LOGGING -DWITH_GHOST_WAYLAND_LIBDECOR -DWITH_HIP -DWITH_HIP_DYNLOAD -DWITH_NANOVDB -DWITH_OCIO -DWITH_OPENSUBDIV -DWITH_OPENVDB -DWITH_OPENVDB_BLOSC -DWITH_OSL -DWITH_SYSTEM_PUGIXML -DWITH_USD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__LITTLE_ENDIAN__ -I/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/../../extern/cuew/include -I/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/../../extern/hipew/include -I/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/../atomic -I/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/scene/.. -I/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/scene/../../sky/include -isystem /usr/include/OpenEXR -isystem /usr/include/Imath -isystem /builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/extern/glog/include -isystem /builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/extern/gflags/src -Wuninitialized -Wredundant-decls -Wall -Wno-invalid-offsetof -Wno-sign-compare -Wlogical-op -Winit-self -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Werror=return-type -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith -Wunused-parameter -Wwrite-strings -Wundef -Wcomma-subscript -Wformat-signedness -Wrestrict -Wno-suggest-override -Wuninitialized -Wno-stringop-overread -Wno-stringop-overflow -Wimplicit-fallthrough=5 -Wundef -Wmissing-declarations -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,--as-needed -fopenmp -pipe -fPIC -funsigned-char -fno-strict-aliasing -fmacro-prefix-map="/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/"="" -fmacro-prefix-map="/builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/redhat-linux-build/"="" -fno-trapping-math -fno-math-errno -fno-signed-zeros -ffp-contract=fast -freciprocal-math -fno-signaling-nans -fno-rounding-math -Wno-error=unused-macros -Wno-maybe-uninitialized -DNDEBUG -std=c++17 -MD -MT intern/cycles/scene/CMakeFiles/cycles_scene.dir/image_vdb.cpp.o -MF intern/cycles/scene/CMakeFiles/cycles_scene.dir/image_vdb.cpp.o.d -o intern/cycles/scene/CMakeFiles/cycles_scene.dir/image_vdb.cpp.o -c /builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/scene/image_vdb.cpp In file included from /usr/include/nanovdb/util/CreateNanoGrid.h:84, from /usr/include/nanovdb/util/OpenToNanoVDB.h:15, from /builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/intern/cycles/scene/image_vdb.cpp:15: /usr/include/nanovdb/util/GridBuilder.h: In member function ‘bool nanovdb::build::LeafNode<BuildT>::ValueIterator::isActive() const’: /usr/include/nanovdb/util/GridBuilder.h:1161:72: error: ‘const struct nanovdb::build::LeafNode<BuildT>’ has no member named ‘isActive’ [-Wtemplate-body] 1161 | bool isActive() const { NANOVDB_ASSERT(*this); return mParent->isActive(mPos);} | ^~~~~~~~
Looks like the most recent openvdb has nanovdb disabled, so we could try this again. I'll run a scratch build and see what happens.
(In reply to Adam Williamson from comment #6) > Looks like the most recent openvdb has nanovdb disabled, so we could try > this again. I'll run a scratch build and see what happens. As far as I know, this should build successfully with the latest usd, https://src.fedoraproject.org/rpms/usd/pull-request/31, unless something else broke in the five days since I tried it in https://copr.fedorainfracloud.org/coprs/music/usd-25.02/packages/. The usd update is ABI-incompatible, so I had to announce it on the devel list with one week’s notice. I’m planning to build it on 2025-01-29.
Welp, my scratch build didn't even make it through build deps: DEBUG util.py:459: Failed to resolve the transaction: DEBUG util.py:459: Problem 1: package openshadinglanguage-devel-1.13.12.0-3.fc42.ppc64le from build requires liboslexec.so.1.13()(64bit), but none of the providers can be installed DEBUG util.py:459: - package openshadinglanguage-devel-1.13.12.0-3.fc42.ppc64le from build requires liboslquery.so.1.13()(64bit), but none of the providers can be installed DEBUG util.py:459: - package openshadinglanguage-devel-1.13.12.0-3.fc42.ppc64le from build requires liboslcomp.so.1.13()(64bit), but none of the providers can be installed DEBUG util.py:459: - package openshadinglanguage-devel-1.13.12.0-3.fc42.ppc64le from build requires liboslnoise.so.1.13()(64bit), but none of the providers can be installed DEBUG util.py:459: - package openshadinglanguage-devel-1.13.12.0-3.fc42.ppc64le from build requires libtestshade.so.1.13()(64bit), but none of the providers can be installed DEBUG util.py:459: - package openshadinglanguage-devel-1.13.12.0-3.fc42.ppc64le from build requires openshadinglanguage-libs(ppc-64) = 1.13.12.0-3.fc42, but none of the providers can be installed DEBUG util.py:459: - conflicting requests DEBUG util.py:459: - nothing provides libOpenImageIO_Util.so.2.5()(64bit) needed by openshadinglanguage-libs-1.13.12.0-3.fc42.ppc64le from build DEBUG util.py:459: - nothing provides libOpenImageIO.so.2.5()(64bit) needed by openshadinglanguage-libs-1.13.12.0-3.fc42.ppc64le from build DEBUG util.py:459: Problem 2: package openshadinglanguage-common-headers-1.13.12.0-3.fc42.noarch from build requires openshadinglanguage = 1.13.12.0-3.fc42, but none of the providers can be installed DEBUG util.py:459: - conflicting requests DEBUG util.py:459: - nothing provides libOpenImageIO_Util.so.2.5()(64bit) needed by openshadinglanguage-1.13.12.0-3.fc42.ppc64le from build DEBUG util.py:459: - nothing provides libOpenImageIO.so.2.5()(64bit) needed by openshadinglanguage-1.13.12.0-3.fc42.ppc64le from build DEBUG util.py:608: Child return code was: 1
Hmm, looks like we have an ABI break in OpenImageIO. That will have broken the existing usd build in Rawhide, so I can probably rush in the new update. I’ll take a look at what needs to be rebuilt a little later.
yeah, the ABI break is why I got here in the first place (current blender build is no longer installable, which breaks the design suite).
(In reply to Adam Williamson from comment #10) > yeah, the ABI break is why I got here in the first place (current blender > build is no longer installable, which breaks the design suite). Ironically, I’m the one who kicked off the OpenImageIO build that broke things, since OpenImageIO had dependency issues that kept it from getting built in the mass rebuild – see discussion in bug 2339861 – but I did not notice that a there was a latent major-version update committed to dist-git that had never been built. That’s a common story this mass-rebuild cycle… It’s probably best if I try everything in COPR before rebuilding anything that depends on OpenImageIO, in case it turns out that we have to revert the update and add an Epoch to OpenImageIO instead of moving forward.
In an email to the devel list on 2024-11-27[1], Richard Shaw wrote about updating to OpenImageIO 3: It looks like openshadinglanguage has not made a release that's compatible with OIIO 3.x so for now I'm abandoning my efforts. Considering the results of a test in COPR[2], it looks like nothing has changed with regard to openshadinglanguage support, and I note that we have the latest version packaged. I think it’s going to be necessary to add an Epoch to OpenImageIO and roll it back to 2.5.16.0. I just opened a PR[3] that would do that. Richard, do you want to weigh in on this? [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SD5N5JEVDBURSJE6VSY5KGKEXEHFKLXG/ [2] https://copr.fedorainfracloud.org/coprs/music/oiio3/packages/ [3] https://src.fedoraproject.org/rpms/OpenImageIO/pull-request/3
Or creating a compatible version like OpenImageIO25 similar to say embree3.
AFAIK, OSL is optional for OIIO (used for some specific tests only), the real dependency goes the other way... I think one ideally wants F42 to ship OIIO 3.x and friends for the VFX CY2025 reference platform: https://vfxplatform.com/#reference-platform
Switching to OSL 1.14-dev might also be an option, see note here https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/releases/tag/v1.13.12.0
(In reply to Miloš Komarčević from comment #14) > AFAIK, OSL is optional for OIIO (used for some specific tests only), the > real dependency goes the other way... Correct, it’s OSL that depends on OIIO, but then usd and blender depend on OSL, so we do need OSL. Both have bconds that can disable OSL support, but I doubt that giving up on OSL is something we want to do. > I think one ideally wants F42 to ship OIIO 3.x and friends for the VFX > CY2025 reference platform: https://vfxplatform.com/#reference-platform (In reply to Miloš Komarčević from comment #15) > Switching to OSL 1.14-dev might also be an option, see note here > https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/releases/ > tag/v1.13.12.0 Hmm, that might work. I’ll see if I can work up a PR and test it in COPR. I’m not really excited about this approach, but it might make sense anyway. I’m curious what the other openshadinglanguage maintainers @luya_tfz, @aekoroglu.com, and @negativo17 think.
OTOH, looks like quite a few people are sitting on OIIO 2.5.x for now - not a direct requirement for the VFX platform, for which OCIO 2.4.x is already available in F42. FWIW, OIIO 2.5.18.0 is out though...
Packaging the tagged v1.14.2.0-dev release of openshadinglanguage would require the openshadinglanguage package to go back from depending on llvm (19) to depending on the llvm18 compat package, which is disappointing but viable. However, v1.14.2.0-dev doesn’t look too happy with OIIO 3 anyway: /builddir/build/BUILD/openshadinglanguage-1.14.2.0_dev-build/OpenShadingLanguage-1.14.2.0-dev/src/liboslexec/oslexec_pvt.h:2496:28: error: cannot convert ‘const OpenImageIO_v3_0::Tex::InterpMode’ to ‘int’ in assignment 2496 | mode = TextureOpt::InterpSmartBicubic; | ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ | | | const OpenImageIO_v3_0::Tex::InterpMode Plus, there seem to be some GCC 15 issues in the tagged release: /builddir/build/BUILD/openshadinglanguage-1.14.2.0_dev-build/OpenShadingLanguage-1.14.2.0-dev/src/include/OSL/dual.h:207:18: error: ‘const class OSL_v1_14_2::DualStorage<T, 3>’ has no member named ‘dz’; did you mean ‘m_dz’? [-Wtemplate-body] 207 | , m_dz(other.dz) | ^~ | m_dz We could try an arbitrary recent git snapshot, but I’m even less thrilled with that than with updating openshadinglanguage to a tagged dev release. (In reply to Miloš Komarčević from comment #17) > OTOH, looks like quite a few people are sitting on OIIO 2.5.x for now - not > a direct requirement for the VFX platform, for which OCIO 2.4.x is already > available in F42. Based on my notes above the above, I think I still advocate for the Epoch and rollback to OIIO 2.x. Then if it turns out we can update before F42 deadlines start hitting, in an organized, planned, and coordinated manner – great. > FWIW, OIIO 2.5.18.0 is out though... Good to know. I think we should roll back to the known-working version and *then* test an update rather than rolling back to a new old version, though. Also, I’m not a maintainer of the OpenImageIO package. I care about it and am willing to help out here and there, but I’m probably not going to prepare the update.
I just emailed Richard directly. I would like to resolve the various FTI issues in Rawhide sooner rather than later, but I’d also very much prefer not to use provenpackager privilege to make a significant change like adding an Epoch to OpenImageIO without the regular maintainer’s explicit consent.
We don't *necessarily* need an epoch, we could untag the broken OIIO. `dnf update` does a distro-sync these days, and if we never rebuilt things against the new soname then I'd guess anyone with the package installed never updated to it anyway due to the broken deps. CCing Kevin Fenzi for thoughts on that.
Yeah, I suppose we could untag it. I hate to do that and it might cause a good deal of confusion, but if thats the best way forward we can.
not saying it is, it's just an option. if an epoch is on balance less problematic, let's go with the epoch...
Well as much as I hate an Epoch bump, if that's the collective call I'll merge the PR.
FEDORA-2025-c40e97c2bd (blender-4.3.2-4.fc42 and usd-25.02-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-c40e97c2bd
FEDORA-2025-c40e97c2bd (blender-4.3.2-4.fc42 and usd-25.02-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.