Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2272507
Summary: | F41FailsToInstall: usd-libs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fedora Fails To Install <fti-bugs> |
Component: | usd | Assignee: | Luya Tshimbalanga <luya_tfz> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | aekoroglu, code, luya_tfz, negativo17 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | usd-23.11-10.fc41 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-04-03 13:54:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2260877 |
Description
Fedora Fails To Install
2024-04-01 17:39:19 UTC
Preparing to rebuild for an unannounced SONAME bump in https://bodhi.fedoraproject.org/updates/FEDORA-2024-520f9008dd. A follow-up to https://bugzilla.redhat.com/show_bug.cgi?id=2262330#c6: Luya, I see now that you were already taking care of the rebuild[1]. Unfortunately, the build failed[2]. Working in a side tag and ideally doing some kind of impact check / test build ahead of time would still make this a lot cleaner and safer. [1] https://src.fedoraproject.org/rpms/usd/c/d2b6fdaf414e48f7ad4da1eaee2be65728823e93?branch=rawhide [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2427991 ---- It looks the current and compat versions of tbb are now both linked in. That’s an issue, and we’ll need to make sure the stack is using one or the other. /usr/bin/ld: warning: libtbb.so.12, needed by /usr/lib64/libOpenImageIO.so, may conflict with libtbb.so.2 /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::setStreamMetadataPtr(std::ios_base&, std::shared_ptr<openvdb::v11_0::io::StreamMetadata>&, bool)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::uninitialize()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::MappedFile::createBuffer() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::DelayedLoadMetadata::getMask(unsigned long) const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::beginName() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::GridBase::META_FILE_BBOX_MIN' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::GridBase::META_FILE_BBOX_MAX' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::StreamMetadata::gridMetadata()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::unzipFromStream(std::istream&, char*, unsigned long)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::close()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getDataCompression(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::initialize()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::endName() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::GridBase::getName[abi:cxx11]() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::GridDescriptor::nameAsString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getStreamMetadataPtr(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getHalfFloat(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::isOpen() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::bloscFromStream(std::istream&, char*, unsigned long)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::readGrid(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, openvdb::v11_0::math::BBox<openvdb::v11_0::math::Vec3<double> > const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getGridBackgroundValuePtr(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getFormatVersion(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::File(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::StreamMetadata::leaf() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::DelayedLoadMetadata::getCompressedSize(unsigned long) const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::open(bool, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)> const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::StreamMetadata::delayedLoadMeta() const' collect2: error: ld returned 1 exit status Also, it seems like something is going on with openvdb. Let me know, what, if anything, you want me to try to help with here. Yes, please. For some reasons, the best on COPR went fine but failed on the main repository. It looks like the packages that depend on openvdb needed to be rebuilt for the ABI change in https://src.fedoraproject.org/rpms/openvdb/c/0a623bb75651129b8062f834eebea18f89e3caec?branch=rawhide. I’m doing a local test-rebuild to try to confirm this theory. If it’s correct, but presumably luxcorerender, openvkl, and prusa-slicer probably need to be rebuilt too (and of course blender, but the FTBFS must be fixed first). If I get a usable local test-rebuild of usd, I’ll go ahead and open a side tag and take care of these rebuilds. I’m only looking at Rawhide right now. I have no idea what the current situation is in F40. Sidetag is ready for F40 on 'fedpkg build --target=f40-build-side-86961'. FEDORA-2024-be3463bb24 (luxcorerender-2.7-0.16.beta1.fc41, OpenImageIO-2.5.7.0-2.fc41, and 3 more) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-be3463bb24 (In reply to Fedora Update System from comment #6) > FEDORA-2024-be3463bb24 (luxcorerender-2.7-0.16.beta1.fc41, > OpenImageIO-2.5.7.0-2.fc41, and 3 more) has been submitted as an update to > Fedora 41. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-be3463bb24 Everything that depended on openvdb rebuilt successfully in F41 except blender, which still failed (in a scratch build) with: /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined reference to 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb::v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock const&)' /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined reference to 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb::v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock const&)' /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined reference to 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb::v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock const&)' collect2: error: ld returned 1 exit status FEDORA-2024-be3463bb24 (luxcorerender-2.7-0.16.beta1.fc41, OpenImageIO-2.5.7.0-2.fc41, and 3 more) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. (In reply to Luya Tshimbalanga from comment #5) > Sidetag is ready for F40 on 'fedpkg build --target=f40-build-side-86961'. Can you please take care of the builds for this one, since as the creator of the side tag, you’ll have to create the (ABI-breaking!) update anyway? A good build order (given openvdb is done) is: 1. koji wait-repo f40-build-side-86961 --build=openvdb-11.0.0-7.fc40 2. bump releases and build OpenImageIO, openvkl, prusa-slicer 3. koji wait-repo f40-build-side-86961 --build=OpenImageIO-2.5.7.0-2.fc40 4. bump releases and build luxcorerender, usd 5. koji wait-repo f40-build-side-86961 --build=usd-23.11-10.fc40 6. do a scratch-build of blender in the side tag and see what it looks like (Some of the release numbers in the koji wait-repo commands might be a little different, depending on how you handle the release bumps.) (In reply to Ben Beasley from comment #7) > Everything that depended on openvdb rebuilt successfully in F41 except > blender, which still failed (in a scratch build) with: > > /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined > reference to > 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb:: > v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock > const&)' > /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined > reference to > 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb:: > v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock > const&)' > /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined > reference to > 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb:: > v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock > const&)' > collect2: error: ld returned 1 exit status Note that I won’t be attempting to debug this. |