FindCUDAToolkit.cmake finds incompatible version of librt

Accelerated Computing CUDA CUDA NVCC Compiler
,
1

I am using “owl” in combination with OptiX and cuda to ray cast a scene. Recently, I switched to Ubuntu 21.10 from Ubuntu 20.04 LTS which also means a switch to a different Cuda (11.5.119), gcc (11.2) and Cmake (3.18.4) version. Since then I am not able to build “owl” any more.

It fails with

nvlink fatal : Could not open input file ‘/usr/lib/x86_64-linux-gnu/librt.a’

The librt.a under this specific path seems to be incompatible with nvcc because when only allowing libraries under that path, building with the verbose option says it’s incompatible (among other libraries). However, FindCUDAToolkit.cmake finds this particular version of rt and adds this specific path to the target CUDA::cudart_static_deps which then results in above linker error (because owl links to CUDA::cudart_static). When only compiling with -lrt, everything works fine.

This issue wasn’t present before because the CMake version was below 3.17 and FindCUDAToolkit is present only since 3.17.

Not sure if this is something that can be fixed from the cuda side of things or if I should rather address the CMake people. Maybe someone can shed some light if this version of librt is supposed to be incompatible? As I haven’t found anything about this issue, it doesn’t seem to be common.

2 Likes
2

I’m facing the same issue, even with cmake 3.14, and with 3.20.2., which leads me to believe that something may be wrong with the librt.a or with how nvcc tries to handle it.
Which kernel version are you using? I recently updated my kernel manually from to 5.14 because of an issue with the suspend of my laptop.

3

find_package(CUDA 11.0 REQUIRED)
string(REPLACE “/usr/lib/x86_64-linux-gnu/librt.a” “” CUDA_LIBRARIES “${CUDA_LIBRARIES}”)

This will make it compile. I don’t know what happens at runtime though if you use this workaround. In my case I can’t actually run the code on the machine I use for developing anyway because I don’t have a NVIDIA GPU. On the machine/cluster I actually compile+run I don’t encounter this error, fortunately.

4

I observe the same problem when trying to build stuff on my Fedora 35 workstation using CUDA 11.6.0, CMake 3.22.1 and gcc 10.3.0 (all installed with spack). It seems like an CMake issue to me. Has anyone notified them about it yet?

5

On the other hand the CUDA docs say that CUDA 11.6.0 is compatible with Fedora 35 and it’s glibc 2.34 which provides the librt.a in question.

6

It seems like problem in nvlink and new glibc incompatibility. I’ve faced it on archlinux recently and here is my post on Reddit. First reply explains things greatly.

2 Likes
7

as discussed on andrew-aralov’s reddit post, a work-around is to replace the glibc librt.a with an empty library which nvlink can link against.

touch empty.c
gcc -c empty.c
ar -cq librt.a empty.o

Then replace /usr/lib/x86_64-linux-gnu/librt.a (or /usr/lib/librt.a in my case) with your dummy librt.a. Did the trick for me.

Note that (as per the reddit post) librt functionality is implemented in libc now.

1 Like
8

Great that I did not get any notifications for the post up until the last answer but the solution works like a charm.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.