Exported cmake targets embed absolute path to libnuma, breaking cross-distro consumption

[mroeschke]

This issue was discovered by trying to build rapidsmpf from source in a cudf devcontainer, which pulls in cuCascade. I'm not a cmake expert, but posting Claude's summary of the issue

---

The exported cuCascadeTargets.cmake embeds an absolute path to libnuma.so (e.g. /usr/lib64/libnuma.so), which breaks consumers on systems where libnuma is installed at a different path.

For example, when the cuCascade cmake package is shipped inside a pip wheel built on a manylinux (RHEL-based) system, the exported targets reference /usr/lib64/libnuma.so. On Ubuntu arm64, libnuma lives at /usr/lib/aarch64-linux-gnu/libnuma.so, causing ninja to fail:

ninja: error: '/usr/lib64/libnuma.so', needed by 'librapidsmpf.so', missing and no known rule to make it

(Human note: Seen in https://github.com/rapidsai/cudf/actions/runs/25450202151/job/74665896167?pr=22281#step:9:14560)

The following line resolves libnuma to an absolute path

cuCascade/CMakeLists.txt

Line 54 in 73d00c4

find_library(NUMA_LIB numa REQUIRED)

That absolute path is then linked as a public dependency

cuCascade/CMakeLists.txt

Line 125 in 73d00c4

Threads::Threads ${NUMA_LIB})

When CMake exports the install targets, ${NUMA_LIB} (e.g. /usr/lib64/libnuma.so) is serialized into cuCascadeTargets.cmake as a literal path.

Suggested fix

Link with the plain library name instead of the absolute path so the exported targets use -lnuma rather than a hardcoded path:

set(CUCASCADE_PUBLIC_LINK_LIBS rmm::rmm cudf::cudf CUDA::cudart
    Threads::Threads numa)

The existing find_library(NUMA_LIB numa REQUIRED) can remain as a build-time check that the library exists.

Then add a find_library in cuCascadeConfig.cmake.in so consumers also verify libnuma is available:

find_library(NUMA_LIB numa REQUIRED)