[OpenMP] [runtime] Broken MacOS build in 21.1.0+ if hwloc is turned on

[rbberger]

We are seeing new build failures on MacOS while trying to package LLVM 21.1.0 for Spack compared to 20.1.8.

kmp_alloc.cpp:1549:46: error: unknown type name 'hwloc_membind_policy_t'
 1549 | static bool __kmp_is_hwloc_membind_supported(hwloc_membind_policy_t policy) {

My initial diagnosis is that recent code changes in openmp/runtime introduced this bug due to the following:

• The hwloc.h is only included on systems with KMP_AFFINITY_SUPPORTED, which is not the case for Darwin.
• kmp_alloc.cpp has now has code parts that use the hwloc API but only guards them with KMP_USE_HWLOC instead of KMP_USE_HWLOC && KMP_AFFINITY_SUPPORTED.

[llvmbot]

@llvm/issue-subscribers-openmp

Author: Richard Berger (rbberger)

We are seeing new build failures on MacOS while trying to [package LLVM 21.1.0 for Spack](https://github.com/spack/spack-packages/pull/1212#issuecomment-3248022549) compare to `20.1.8`.

kmp_alloc.cpp:1549:46: error: unknown type name 'hwloc_membind_policy_t'
 1549 | static bool __kmp_is_hwloc_membind_supported(hwloc_membind_policy_t policy) {

My initial diagnosis is that recent code changes in openmp/runtime introduced this bug due to the following:

• The hwloc.h is only included on systems with KMP_AFFINITY_SUPPORTED, which is not the case for Darwin.
• kmp_alloc.cpp has now has code parts that use the hwloc API but only guards them with KMP_USE_HWLOC instead of KMP_USE_HWLOC && KMP_AFFINITY_SUPPORTED.

[rbberger]

@nawrinsu @rorth please take another look. Seems like that initial PR was from some LLM bot that has now deleted its GitHub account.

[rorth]

I'm about to fire off Solaris/sparcv9 and Solaris/amd64 builds to check. openmp (like flang and mlir) isn't included in the Solaris bots. In the flang/mlir case, memory and cpu consumption are excessive, for openmp parallel testing with ninja -jN times ncores (since OMP_NUM_THREADS defaults to ncores) drives the load to excessive heights, rendering the systems close to unusable.

[rorth]

Both builds have completed successfully: no issues with openmp or otherwise.

[rbberger]

@rorth did those builds use -DLIBOMP_USE_HWLOC=ON? The preprocessor logic is pretty simple and obviously wrong. It solely relies on KMP_USE_HWLOC for using the hwloc API, while the condition for hwloc.h header inclusion is more restrictive.

[rorth]

They didn't and cannot out of the box: Solaris doesn't bundle libhwloc, in fact before now I didn't even know it exists.

I've checked the program's homepage now: it claims to support Solaris, but such claims are often outdated. I'd have to check myself. But even if that's true, there is at least one issue: if a non-privileged users installs it, it had to be in a non-system directory. In order for libhwloc.so to be found at runtime as a dependency of libomp.so, that would have to built with the appropriate runpath, and I've seen no provision to add that in the openmp configury right now.