Bug#1132157: onetbb: Please include support for GNU Hurd

Petter Reinholdtsen pere at hungry.com
Sat Apr 4 21:42:52 BST 2026


I've managed to get the upstream version working on GNU Hurd, at least
two third of the time. :)

Four of patches have been applied upstream already:

 * Provide useful PTHREAD_STACK_MIN value if OS do not define it.
   https://github.com/uxlfoundation/oneTBB/pull/2026
 * Disabled increased_priority_guard on GNU Hurd.bug fix
   https://github.com/uxlfoundation/oneTBB/pull/2028
 * Extend gcc 12-14 workaround in notify_one_relaxed() to 15
   https://github.com/uxlfoundation/oneTBB/pull/2029
 * Fixed GNU Hurd test runs checking arena handling.
   https://github.com/uxlfoundation/oneTBB/pull/2038

Five of the patches remain to be accepted:

 * Removed artificial PATH_MAX limits.bug fix
   https://github.com/uxlfoundation/oneTBB/pull/2025
 * Stop trying to parse GNU Hurd kernel version as a Linux kernel version.
   https://github.com/uxlfoundation/oneTBB/pull/2031
 * Adjusted test_lightweight to avoid zero threads in test.
   https://github.com/uxlfoundation/oneTBB/pull/2033
 * Limit cleanup loop in test_tbb_fork to 5 iterations.
   https://github.com/uxlfoundation/oneTBB/pull/2041
 * Fixed conformance_arena_constraints test failure with no NUMA hardware.
   https://github.com/uxlfoundation/oneTBB/pull/2042

It is worth noting that the patch in #2041 reduce the inpact of some
kind of race condition in the signal handling in Hurd, which some times
lead to failures.  The patch do not fix the problem, just make sure the
failure do not cause an endless loop.  The problem trigger around 1/3 of
the times I run test_tbb_fork locally.

My offer to backport the patches still stand, but it might make more
sense to wait for a new upstream release before enabling Hurd support.

-- 
Happy hacking
Petter Reinholdtsen



More information about the debian-science-maintainers mailing list