According to FFmpeg developers, the NVCC compiler is currently not compatible with the newly released glibc 2.26.
Discussion here: https://trac.ffmpeg.org/ticket/6648.
I’m currently using CUDA/NVCC 8.0.61 and it produces errors with glibc 2.26.
When trying to compile FFmpeg or Caffe2 with CUDA support I’m getting these errors:
/usr/include/bits/floatn.h(61): error: invalid argument to attribute "__mode__"
/usr/include/bits/floatn.h(73): error: identifier "__float128" is undefined
Can you please add glibc 2.26 support to CUDA/NVCC 8?
Thank you.
CUDA 8 is not likely to be updated at this point, as release of CUDA 9 is “soon”.
You might want to test with CUDA 9 RC. (it may not work properly there either - 2.26 appears to be quite recent)
Also, requests of this type should be filed at developer.nvidia.com using the bug report system, not here on the forum, if you want the best possibility for a future change.
Taking a look at the CUDA 9 RC linux install guide, I see:
Is not upgrading to glibc 2.26 not a feasible way to avoid the issue? I assume Linux hasn’t become Windows 10 yet, where users may be forced to upgrade.
Alternatively, you could file a bug with the glibc maintainers, pointing out that whatever interface changes they made broke existing applications (a big no-no in my book). I somewhat doubt this would do any good, as the Linux world often gives a rodent’s behind about backward compatibility.
Did you install glibc 2.26 because your application requires a particular feature that is new to this version of the library? If not, you should be able to downgrade it.
Out of curiosity, did the release notes for glibc 2.26 point out that it contains interface changes that may break existing applications?
Sorry to hear that. I had never heard of Tumbleweed. I took a look at [url]https://en.opensuse.org/Portal:Tumbleweed[/url] and haven’t been able to figure out why any regular developer (i.e. not directly involved with the development of Linux itself) would want to use it. In software, newer does not always mean better, and there is rarely a good reason to be on the bleeding edge.
Tumbleweed has never been among the supported platforms for CUDA.
Having said that, I have successfully used CUDA on Tumbleweed for a couple of years. That involved checking of updates and installing matching compiler versions on my own. Admittedly though, I’ve never used OpenGL interop because that would have involved downgrading half of the system, or separately installing older versions of about everything graphics related.
You can normally roll back a problematic update using btrfs checkpoints, provided you had allocated enough space on the root filesystem. (yast2 automatically checkpoints before and after updates, as well as many other administration tasks).
CUDA 9.0RC
After not finding a conventional solution for Tumbleweed I did an evil thing and edited the file
/usr/include/bits/floatn.h
and short circuited the __HAVE_FLOAT128
/* Defined to 1 if the current compiler invocation provides a
floating-point type with the IEEE 754 binary128 format, and this
glibc includes corresponding *f128 interfaces for it. The required
libgcc support was added some time after the basic compiler
support, for x86_64 and x86. */ #if (defined x86_64
? __GNUC_PREREQ (4, 3)
: (defined GNU ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
It would have been nice if NVCC had a command line option that would have turned off
Anyway short circuiting __HAVE_FLOAT128 should not cause any harm in the big picture of things.
do in the following on the command line I was able to successfully build all the cuda samples and test them
export HOST_COMPILER=/usr/bin/g+±6
Only odd thing is I have to run all my CUDA as root. If I run any of the samples as a normal user I get an error similar to
/1_Utilities/deviceQuery/deviceQuery
./1_Utilities/deviceQuery/deviceQuery Starting…
CUDA Device Query (Runtime API) version (CUDART static linking)
cudaGetDeviceCount returned 38
→ no CUDA-capable device is detected
Result = FAIL
I don’t get the error if I run at root user. Can anyone recommend a fix