The current version of tbb packaged in all Fedora versions is 2020.3 (from July 2020), but upstream has released version 2021.5.0 now. Please update the version in Fedora.
Unfortunately, this is not a simple matter. The 2021.1.1 release introduced backwards incompatible changes, notably the complete removal of commonly used interfaces. See https://www.intel.com/content/www/us/en/developer/articles/technical/tbb-revamp.html for details. Simply updating to the latest tbb release would break many Fedora packages. On the other hand, some Fedora packages could move to the latest release were it available. I've got a COPR repo at https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ that can be used to check compatibility. We could introduce a tbb 2020 compatibility package, and then move the main package forward to 2021.5.0. The danger then is that some application might end up with both the old and the new versions of the library due to some dependencies moving forward and others not. I have tried to map out the space of Fedora tbb-using packages. I believe these are the blocks of packages that need to move forward simultaneously to avoid trouble: - fawkes, gazebo - opencascade - pmemkv - root - 4ti2, blender, bowtie2, coin-or-Cbc, coin-or-Cgl, coin-or-Clp, coin-or-CoinUtils, coin-or-Osi, dyninst, embree, gap-pkg-hapcryst, gap-pkg-happrime, gap-pkg-polymaking, gap-pkg-singular, gegl04, giac, gimp, glpk, gnome-photos, gutenprint, latte-integrale, luxcorerender, Macaulay2, mathicgb, oidn, opencv, OpenImageIO, opensubdiv, openvdb, polymake, prusa-slicer, pynac, python-cvxopt, python-jupymake, python-jupyter-kernel-singular, python-jupyter-polymake, python-pysingular, qepcad-B, sagemath, Singular, suitesparse, systemtap, xsane-gimp That last group is, of course, the main issue. The dependencies are so intertwined that none of them can move to the new version of tbb until all of them can. That means that we can have at most 5 packages move to the new version right away: fawkes, gazebo, opencascade, pmemkv, and root. That hardly seems worth the effort. What we need to do is start going through all of these packages to find which are able to upgrade and which are not, then start filing upstream bugs on those that are not. Some of the upstreams have not been active for quite awhile, so we may find ourselves needing to the the ports ourselves, which does not appear to be a trivial task. At one point, I intended to do all this work myself. But see my recent email to fedora-devel-list about retiring from the mathematical packages I have been tending. I am trying to move away from the packages I maintain that use tbb, which is a demotivator to put a lot of work into tbb. Volunteers are welcome.
I think I'd like to explore moving forward with a tbb-compat package based on 2020.3 but I don't have a timeframe yet for when I might undertake that work.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
For anyone interested, I have updated my COPR of tbb for version 2021.7.0: https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/
I think at this point we don't have a choice, we need a parallel installable compat package. I don't have a lot of time and I'm not familiar with the building of TBB, but I can carve out some cycles to help work on this.
*** Bug 2156800 has been marked as a duplicate of this bug. ***
(In reply to Richard Shaw from comment #6) > I think at this point we don't have a choice, we need a parallel installable > compat package. I don't have a lot of time and I'm not familiar with the > building of TBB, but I can carve out some cycles to help work on this. I agree. I have recently been looking into doing this. My current thinking is to continue to publish the 2020.3 version as a tbb2020.3 package, and move the tbb package to track upstream. The complication is that it does not appear that I can do this in a way that would allow parallel installation of both packages.
(In reply to Thomas Rodgers from comment #8) > (In reply to Richard Shaw from comment #6) > > I think at this point we don't have a choice, we need a parallel installable > > compat package. I don't have a lot of time and I'm not familiar with the > > building of TBB, but I can carve out some cycles to help work on this. > > I agree. I have recently been looking into doing this. My current thinking > is to continue to publish the 2020.3 version as a tbb2020.3 package, and > move the tbb package to track upstream. > > The complication is that it does not appear that I can do this in a way that > would allow parallel installation of both packages. In terms of 'when' this could land in a Fedora release, the deadline for system-wide chnage proposals for Fedora 38 has passed. This would need to target f39.
If we can come up with a parallel installable package, I don't think this requires any sort of "system wide change" proposal/approval. It should "just work".
(In reply to Richard Shaw from comment #10) > If we can come up with a parallel installable package, I don't think this > requires any sort of "system wide change" proposal/approval. It should "just > work". The deadline for self-contained changes is Jan 17, so that doesn't leave a lot of time to get the change proposal in and approved by fesco. I already have an approved system-wide change (boost 1.81) targeting f38 which has to take priority, so I don't practically see how I can get this done for f38.
I don't see how you can possibly make a compat package if tbb hasn't bumped the soname of the library. Can you get upstream to bump the soname if they really have changed the ABI?
(In reply to Orion Poplawski from comment #12) > I don't see how you can possibly make a compat package if tbb hasn't bumped > the soname of the library. Can you get upstream to bump the soname if they > really have changed the ABI? They bumped the soname of tbb .so, just not the tbbmalloc.so...so "worst of all possible choices", though logical, the ABI of tbbmalloc hasn't changed.
(In reply to Thomas Rodgers from comment #13) > (In reply to Orion Poplawski from comment #12) > > I don't see how you can possibly make a compat package if tbb hasn't bumped > > the soname of the library. Can you get upstream to bump the soname if they > > really have changed the ABI? > > They bumped the soname of tbb .so, just not the tbbmalloc.so...so "worst of > all possible choices", though logical, the ABI of tbbmalloc hasn't changed. So to answer the original question, sure, I can ask. I work with the TBB team on other things. I prefer that this all be parallel-installable. Gettting from here...to...there... will take work, also time, I'm going to target, tentatively, f39.
Can we split libtbbmalloc.so into a separate package, and make tbb-compat depend on it? So libtbbmalloc.so would come from the newer TBB package, and both tbb and tbb-compat would depend on it.
(In reply to Jonathan Wakely from comment #15) > Can we split libtbbmalloc.so into a separate package, and make tbb-compat > depend on it? I mean subpackage, of course. It would come from the same SRPM as the 'tbb' RPM.
Strictly speaking we don't even need a subpackage, because 'tbb-compat' could just depend on 'tbb' and get libtbbmalloc.so and libtbbmalloc_proxy.so that way. It might be slightly cleaner to split 'tbb' into 'tbb' and 'tbb-libtbbmalloc' (or another name) but it's not actually necessary to make it work.
I've put my stab at a compat package here: https://copr.fedorainfracloud.org/coprs/orion/tbb-compat/ Tests appear to be hanging on ppc64le for some unknown reason. Strategy is to just build libtbb and depend on the rest from the tbb package as Jonathan Wakely suggests. Probably should also drop the python package from it as well because it conflicts and doesn't really
I've dropped the python package and the ppc64le hang seems to be intermittent - haven't seen it again.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
(In reply to Thomas Rodgers from comment #2) > I think I'd like to explore moving forward with a tbb-compat package based > on 2020.3 but I don't have a timeframe yet for when I might undertake that > work. (In reply to Orion Poplawski from comment #18) > I've put my stab at a compat package here: https://copr.fedorainfracloud.org/coprs/orion/tbb-compat/ Tests appear to be hanging on ppc64le for some unknown reason. > Strategy is to just build libtbb and depend on the rest from the tbb package as Jonathan Wakely suggests. > Probably should also drop the python package from it as well because it conflicts and doesn't really I am about to mark this Fedora change proposal "ready for wrangler" - https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
> - fawkes, gazebo > - opencascade > - pmemkv > - root > - 4ti2, blender, bowtie2, coin-or-Cbc, coin-or-Cgl, coin-or-Clp, > coin-or-CoinUtils, coin-or-Osi, dyninst, embree, gap-pkg-hapcryst, > gap-pkg-happrime, gap-pkg-polymaking, gap-pkg-singular, gegl04, giac, gimp, > glpk, gnome-photos, gutenprint, latte-integrale, luxcorerender, Macaulay2, > mathicgb, oidn, opencv, OpenImageIO, opensubdiv, openvdb, polymake, > prusa-slicer, pynac, python-cvxopt, python-jupymake, > python-jupyter-kernel-singular, python-jupyter-polymake, python-pysingular, > qepcad-B, sagemath, Singular, suitesparse, systemtap, xsane-gimp Could someone check that all of those packages that depend on tbb are added to https://release-monitoring.org/ ? So we can keep up to date on them as well? That would be awesome. Thanks in advance.
(In reply to romulasry from comment #22) > > - fawkes, gazebo > > - opencascade > > - pmemkv > > - root > > - 4ti2, blender, bowtie2, coin-or-Cbc, coin-or-Cgl, coin-or-Clp, > > coin-or-CoinUtils, coin-or-Osi, dyninst, embree, gap-pkg-hapcryst, > > gap-pkg-happrime, gap-pkg-polymaking, gap-pkg-singular, gegl04, giac, gimp, > > glpk, gnome-photos, gutenprint, latte-integrale, luxcorerender, Macaulay2, > > mathicgb, oidn, opencv, OpenImageIO, opensubdiv, openvdb, polymake, > > prusa-slicer, pynac, python-cvxopt, python-jupymake, > > python-jupyter-kernel-singular, python-jupyter-polymake, python-pysingular, > > qepcad-B, sagemath, Singular, suitesparse, systemtap, xsane-gimp > > Could someone check that all of those packages that depend on tbb are added > to https://release-monitoring.org/ ? So we can keep up to date on them as > well? That would be awesome. Thanks in advance. pmemkv, gap-pkg-happrime, giac, mathicgb, python-jupymake, python-jupyter-kernel-singular, python-jupyter-polymake are missing, the others are there.
(In reply to Jonathan Wakely from comment #23) > pmemkv, gap-pkg-happrime, giac, mathicgb, python-jupymake, > python-jupyter-kernel-singular, python-jupyter-polymake are missing, the > others are there. - pmemkv is retired, present only in F37 (discontinued upstream) - gap-pkg-happrime is retired and not present in any current Fedora release (discontinued upstream) - giac is now configured: https://release-monitoring.org/project/359705/ - mathicgb has a version number but looks like it is one of those projects where the version number never changes and we package snapshots forever, and there are no tags on GitHub - python-jupymake is now configured (but again, we are packaging snapshots): https://release-monitoring.org/project/359707/ - python-jupyter-kernel-singular was already set up when I checked: https://release-monitoring.org/project/57265/ - python-jupyter-polymake has a version number but looks like it is one of those projects where the version number never changes and we package snapshots forever; furthermore, it is not yet on PyPI, and there are no tags on GitHub
Thanks, Ben! I have a copr that contains both tbb-2021.9.0-1.fc39 (based on jjames' copr package) and tbb2020.3-2020.3-1.fc39 (based on Orion's copr package). The analysis for the failed packages is: opensubdiv: /builddir/build/BUILD/OpenSubdiv-3_5_0/opensubdiv/osd/tbbEvaluator.cpp:28:10: fatal error: tbb/task_scheduler_init.h: No such file or directory 28 | #include <tbb/task_scheduler_init.h> This builds OK if switched to use tbb2020.3-devel instead of tbb-devel: https://copr.fedorainfracloud.org/coprs/jwakely/tbb-refresh/build/6119758/ dyninst needs a fix for cmake to find the new TBB: https://src.fedoraproject.org/rpms/dyninst/pull-request/5 But then it fails later due to a dyninst bug (should be easy to fix, I'll deal with it shortly): /usr/include/oneapi/tbb/concurrent_hash_map.h:627:77: error: static assertion failed: value_type of the container must be the same as its allocator's 627 | static_assert(std::is_same<value_type, typename Allocator::value_type>::value, | ^~~~~ /usr/include/oneapi/tbb/concurrent_hash_map.h:627:77: note: 'std::integral_constant<bool, false>::value' evaluates to false /usr/include/oneapi/tbb/concurrent_hash_map.h: In instantiation of 'class tbb::detail::d2::concurrent_hash_map<entryID, std::set<boost::shared_ptr<Dyninst::InstructionAPI::Expression> >, tbb::detail::d1::tbb_hash_compare<entryID>, std::allocator<std::pair<entryID, std::set<boost::shared_ptr<Dyninst::InstructionAPI::Expression> > > > >': /builddir/build/BUILD/dyninst-12.2.0/dyninst-12.2.0/common/h/concurrent.h:56:7: required from 'class Dyninst::dyn_c_hash_map<entryID, std::set<boost::shared_ptr<Dyninst::InstructionAPI::Expression> > >' /builddir/build/BUILD/dyninst-12.2.0/dyninst-12.2.0/instructionAPI/src/Operation.C:387:24: required from here /usr/include/oneapi/tbb/concurrent_hash_map.h:627:77: error: static assertion failed: value_type of the container must be the same as its allocator's gazebo looks like it needs to use tbb2020.3: /builddir/build/BUILD/gazebo-10.1.0/gazebo/transport/Connection.hh:75:20: error: 'task' in namespace 'tbb' does not name a type opencascade needs to use tbb2020.3 or be updated to a new upstream release (see Bug 2217295): /builddir/build/BUILD/occt-V7_6_3/src/OSD/OSD_Parallel_TBB.cxx:28:10: fatal error: tbb/task_scheduler_init.h: No such file or directory usd probably needs a similar cmake fix as dyninst: CMake Error at cmake/modules/FindTBB.cmake:200 (file): file failed to open for reading (No such file or directory): /usr/include/tbb/tbb_stddef.h Call Stack (most recent call first): cmake/defaults/Packages.cmake:155 (find_package) CMakeLists.txt:23 (include) -- Found TBB: /usr/include (found version ".") found components: tbb blender (Bug 2218037), lammps (Bug 2190212), and prusa-slicer (Bug 2217962) are FTBFS in rawhide, unrelated to tbb.
Any update/progress?
Note: as far as OpenCascade is concerned, updating to a new upstream release is highly desirable. The only reason to do a build against the legacy package is to decouple changes, which is probably worthwhile.
(In reply to Richard Shaw from comment #26) > Any update/progress? I couldn't even do scratch builds of the packages that should have moved from tbb to tbb2020.3, due to the python3 breakage that only got resolved hours before the mass rebuild. It would probably be safe to do some of those changes now, since the content of tbb202.3 is currently identical to tbb and so just altering the BuildRequires should have no real effect. But it's too late to update the main tbb package to oneTBB for F39, so it will have to wait until F39 branches and rawhide is open for F40 changes. I'm as frustrated by this as anybody, but the changes I had lined up to push to rawhide were impossible to do until it was too late.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
(In reply to Jonathan Wakely from comment #28) > But it's too late to update the > main tbb package to oneTBB for F39, so it will have to wait until F39 > branches and rawhide is open for F40 changes. > > I'm as frustrated by this as anybody, but the changes I had lined up to push > to rawhide were impossible to do until it was too late. Thus I reassign this issue to version `rawhide`.
So Fedora 39 is out. Any hope of seeing this in Rawhide soon?
It has to go through FESCo approval again: https://pagure.io/fesco/issue/3099 Once that's done (and now that GCC stage 1 is finished) I should be able to do the TBB update.
The Fedora 40 change has been approved: https://fedoraproject.org/wiki/Changes/F40ModernizeTBB
Your post stands out. Unlike others, it left a distinct impression. Hope for more insightful reads like this from you! https://myolsd.top/
FEDORA-2024-7c21b7afa2 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
openvdb has been rebuilt to use tbb-2021.11 but OpenImageIO doesn't build with the new TBB so I switched it to use tbb2020.3, but now the two version conflict because OpenImageIO uses openvdb. This will need to be resolved.
I'm working on a new major version of OIIO with a soname bump. I'll see if I can pick up the new TBB while I'm at it.
Ah great, I'll leave you to sort out the mess I made then (sorry!) The side tag with the new boost and new tbb is f40-build-side-81691 but hopefully we'll be merging it back to rawhide "soon", so you might be better off waiting instead of trying to use that tag.
FEDORA-2024-7c21b7afa2 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
I'm trying to rebuild OIIO but getting a failure only on i686, it looks like maybe openvdb didn't build with the new TBB but only on i686? How would that happen? https://koji.fedoraproject.org/koji/taskinfo?taskID=111947045
Looks like gazebo might need to use the old TBB: /builddir/build/BUILD/gazebo-10.2.0/gazebo/transport/Connection.hh:75:20: error: ‘task’ in namespace ‘tbb’ does not name a type 75 | public: tbb::task *execute() | ^~~~
(In reply to Richard Shaw from comment #41) > I'm trying to rebuild OIIO but getting a failure only on i686, it looks like > maybe openvdb didn't build with the new TBB but only on i686? How would that > happen? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=111947045 Yes, the root.log for the i686 build shows it used tbb2020.3-devel and the root.log for the x86_64 build shows it used tbb-devel. Weird! I assume that on i686 some other BuildRequires pulled in a dependency on libtbb.so and that can be satisfied by either tbb or tbb2020.3, and it happened to pick the former.
Or maybe that's the case for all arches, and it's just non-deterministic which one gets picked? I don't see anything that openvdb BuildRequires that depends on tbb, only this in openvdb.spec itself: BuildRequires: pkgconfig(tbb) >= 3.0 Maybe making that ">= 2021.11" would ensure that the new one is used?
The correct explanation is at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/I24CXF6W6CQI4LQRNYWUWQT5WSDC55TO/