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.
Sorry to hear that. I had never heard of Tumbleweed. I took a look at https://en.opensuse.org/Portal:Tumbleweed 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).
After not finding a conventional solution for Tumbleweed I did an evil thing and edited the file
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)))
define __HAVE_FLOAT128 1
define __HAVE_FLOAT128 0
//Short circuit the float128 feature
define __HAVE_FLOAT128 0
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
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
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