RHEL/CentOS update causes nvcc to fail

Today I applied updates to a CentOS 7 box that included glibc updates (Red Hat Customer Portal - Access to 24x7 support and knowledge). After doing so, I was unable to make the CUDA 10.2 samples on the box. Experiments with nvidia-docker images with CentOS 7 + updates with CUDA 11.2 had the same problem Centos 10.2 devel broken with most recent update (#109) · Issues · nvidia / container-images / cuda · GitLab. As I posted there, nvcc has problems compiling code with certain forms of floating-point constants.

nvcc wants 0.f to be replaced with 0 or 0.0 to be replaced with 0. If the floating point constant needs the extra precision (i.e. 3.408f ) there is no complaint. I discovered this by changing NVIDIA CUDA sample code, but had to stop when system headers used offending floating-point constants.

Any ideas?

1 Like

The nvcc compiler works again if I point LD_LIBRARY_PATH to an extracted copy of 2.17-317’s libc.so.6 & libc-2.17.so, so it seems to be something in the glibc implementation.

If this upstream bug has the same cause, it seems like they’re working on getting it resolved:

Yes, this looks very encouraging! Thanks for the info. Keeping my fingers crossed.

Red Hat has a fix: Red Hat Customer Portal - Access to 24x7 support and knowledge
Now let’s see how long it takes CentOS to incorporate this.

CentOS 7 has the glibc update. Testing as I write this…

I can confirm the glibc patch fixed the problem.

1 Like

Verified here as well, cheers for tracking this problem.


I am a newcomer to this forum, so my apologies if I this is not directly related, but is this the cause of the problems that I have recently started seeing along the lines of

OptiX/include/optixu/optixu_math_namespace.h:594:34: error: expected ‘)’ before numeric constant
return make_float3(a.x, a.y, 0.0f);
~ ^~~

Edit - Looking over the original report, of course it does. My apologies for the noise! Thanks for reporting and following this issue.


1 Like