Project

General

Profile

Task #1982

work around compilation error with nvcc + glibc 2.23

Added by Szilárd Páll over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
build system
Target version:
Difficulty:
uncategorized
Close

Description

With some versions of nvcc and glibc compilation errors occur; reported on gmx-users first and second as well as by multiple other projects.

The issue seems to be cause by a string.h change in glibc and I've reproduced it with CUDA 6.5, 7.0and 7.5, but not with 8.0.


Related issues

Related to GROMACS - Bug #2022: Compilation fails with CUDA and gcc 5Closed

Associated revisions

Revision e2cd2e2e (diff)
Added by Mark Abraham over 3 years ago

Work around glibc 2.23 with CUDA

Fixes #1982

Change-Id: I24671fcbdfdf1fb8bcc178edaeb801e849959266

History

#1 Updated by Mark Abraham over 3 years ago

Further, the issue is not specific to the compiler version (whether supported by CUDA or not), but rather to the version of glibc. Our source code being compiled in those reports is only including stdio.h, but including string.h is something that might happen (transitively) by whatever transformation nvcc does. And probably the issue is not unique to that single file in our source code (since other projects observe the same effect).

The workaround being suggested in various places is to add -D_FORCE_INLINES to the CUDA compiler command line, which disables the new code path in string.h. It is not yet clear what other effects that has in other glibc headers, but some quick grepping suggests it is specific to string-handling headers. In that case we don't care, and can just deploy the hack.

We could compile a test CUDA program (with execute_process()? I'm not sure how we arrange to call nvcc now) and add the flag if that fails, and then give up if there's a further problem. That infrastructure could also help address #1616

#2 Updated by Gerrit Code Review Bot over 3 years ago

Gerrit received a related patchset '1' for Issue #1982.
Uploader: Mark Abraham ()
Change-Id: I24671fcbdfdf1fb8bcc178edaeb801e849959266
Gerrit URL: https://gerrit.gromacs.org/5991

#3 Updated by Mark Abraham over 3 years ago

  • Status changed from New to Fix uploaded
  • Target version set to 2016

#4 Updated by Szilárd Páll over 3 years ago

Thanks for the fix!

Mark Abraham wrote:

We could compile a test CUDA program (with execute_process()? I'm not sure how we arrange to call nvcc now) and add the flag if that fails, and then give up if there's a further problem. That infrastructure could also help address #1616

I thought about hacking up a try_compile_nvcc() in the past, but some technical issues seemed to require more complex solution that what was worth the effort. Otherwise, it should be as simple as calling

nvcc -c test.cu -ccbin /path/to/compiler/binary

and checking its retval.

#5 Updated by Mark Abraham over 3 years ago

  • Status changed from Fix uploaded to Resolved

#6 Updated by Mark Abraham over 3 years ago

  • Status changed from Resolved to Closed

#7 Updated by Mark Abraham over 3 years ago

  • Related to Bug #2022: Compilation fails with CUDA and gcc 5 added

Also available in: Atom PDF