View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014971CMakeCMakepublic2014-06-12 13:542016-06-10 14:31
ReporterAdam Strzelecki 
Assigned ToRobert Maynard 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformAppleOSOSXOS Version10.9.3
Product VersionCMake 3.0 
Target VersionFixed in Version 
Summary0014971: FindCUDA causes error with default Clang installation on OSX 10.9.3 (w/patch)
DescriptionPlease find attached patch for bug fix.

Consider following examples:

CMakeLists.txt
==============
cmake_minimum_required(VERSION 2.6)
project(TestCUDA CXX)
find_package(CUDA)
cuda_add_executable(test_cuda test_cuda.cu)

test_cuda.cu
============
int main(int argc, char const *argv[]) { return 0; }


Now running on my Mac with OSX 10.9.3 I get:

[1/2] Building NVCC (Device) object CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
FAILED: cd /tmp/cuda/CMakeFiles/test_cuda.dir && /Applications/CMake.app/Contents/bin/cmake -E make_directory /tmp/cuda/CMakeFiles/test_cuda.dir//. && /Applications/CMake.app/Contents/bin/cmake -D verbose:BOOL=OFF -D build_configuration:STRING= -D generated_file:STRING=/tmp/cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o -D generated_cubin_file:STRING=/tmp/cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o.cubin.txt -P /tmp/cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.cmake
nvcc warning : The 'compute_10' and 'sm_10' architectures are deprecated, and may be removed in a future release.
-m64: No such file or directory
TagsNo tags attached.
Attached Filespatch file icon 0001-FindCUDA-Fix-compilation-with-Clang-on-OSX.patch [^] (1,736 bytes) 2014-06-12 13:54 [Show Content]
patch file icon 0002-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch [^] (3,521 bytes) 2014-06-27 15:49 [Show Content]
patch file icon 0003-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch [^] (3,632 bytes) 2014-06-27 16:19 [Show Content]

 Relationships

  Notes
(0036170)
Robert Maynard (manager)
2014-06-12 14:01

James,

Can you look over this and see if it looks reasonable to you? If you don't see any issues I will get the merged into master.
(0036171)
Brad King (manager)
2014-06-12 14:06

The proper way to enable a language is via enable_language(C). A direct include(CMakeDetermineCCompiler) is not a clean way to do it.

However, I do not think a find_package(CUDA) call should cause a language to be enabled. Instead it should test the ENABLED_LANGUAGES global property and produce an error if the needed language is not available.
(0036196)
James Bigler (developer)
2014-06-13 13:05

This is not the place to set CUDA_HOST_COMPILER. It should happen above when CUDA_HOST_COMPILER is initialized. I've struggled to figure out a clean way to handle this, and on my own projects I've hard coded the CUDA_HOST_COMPILER to clang. I like this method more.

Put it here:

if(CMAKE_GENERATOR MATCHES "Visual Studio")
  set(CUDA_HOST_COMPILER "$(VCInstallDir)bin" CACHE FILEPATH "Host side compiler used by NVCC")
else()
 + # Using cc which is symlink to clang may let NVCC think it is GCC and issue
 + # unhandled -dumpspecs option to clang.
 + get_filename_component(_cuda_c_compiler_realpath "${CMAKE_C_COMPILER}" REALPATH)
 + set(CUDA_HOST_COMPILER "${_cuda_c_compiler_realpath}" CACHE FILEPATH "Host side compiler used by NVCC")
 - set(CUDA_HOST_COMPILER "${CMAKE_C_COMPILER}" CACHE FILEPATH "Host side compiler used by NVCC")
endif()
(0036197)
James Bigler (developer)
2014-06-13 13:06

I don't have an opinion on the enable_language() part. Please do what is appropriate for CMake. I only had to do this for targets without other source files. I've never tried it with projects that didn't have the C language enabled.
(0036198)
Brad King (manager)
2014-06-13 13:21

Re 0014971:0036196: FYI, as of CMake 3.0 the CMAKE_C_COMPILER is always a full path to the compiler (if C is enabled) even for the Visual Studio generators.
(0036199)
James Bigler (developer)
2014-06-13 13:33

Having the full path to the compiler isn't the same thing as resolving the symbolic links.

/usr/bin/cc is different to CUDA than /usr/bin/clang. At least for now CUDA gets confused and thinks /usr/bin/cc is gcc when in fact it points to clang. At some point in the future this could work again, but for now we need to help CUDA along.
(0036200)
Brad King (manager)
2014-06-13 13:49

Re 0014971:0036199: Yes, using REALPATH will be needed to resolve symbolic links. I meant that we don't need a separate code path for Visual Studio anymore.
(0036201)
Adam Strzelecki (reporter)
2014-06-13 14:24
edited on: 2014-06-13 14:29

Re 0014971:0036196: I don't think we need to force user explicitly specify C as project language since CUDA is C++ - this would be very confusing.

However somewhere behind the scenes NVCC translates C++ CPU part into plain C injecting some extra code then calls host C compiler. Therefore I include CMakeDetermineCCompiler in order to determine CMAKE_C_COMPILER. Not sure if it is proper way to lookup C compiler without changing project languages though.

(0036202)
James Bigler (developer)
2014-06-13 14:43
edited on: 2014-06-13 14:45

Re 0014971:0036200

I don't see how we can get rid of the VS code path. The results are significantly different. For VS I use $(VCInstallDir)bin which is a VS variable that is expanded later. This is different than the non VS case.

(0036255)
Adam Strzelecki (reporter)
2014-06-26 04:25

Re 0014971:0036202

Any news whether this will be merged anytime soon?
(0036262)
James Bigler (developer)
2014-06-26 16:27

Robert, you can merge this in provided the changes I suggested are put into place.
(0036268)
Brad King (manager)
2014-06-27 09:55

FWIW, the patch will not be accepted and merged to master if it still tries to include CMakeDetermineCCompiler. That module is part of the enable_language infrastructure and is not for general use. If we need a valid CMAKE_C_COMPILER then we need to ask the project to enable C itself.

How do we know that NVCC will invoke whatever CMAKE_C_COMPILER gets detected? Perhaps some other process is needed to determine which compiler NVCC will invoke.
(0036270)
James Bigler (developer)
2014-06-27 12:46

OK, so is the action item for Adam to provide a new patch with the requested features?
(0036271)
Robert Maynard (manager)
2014-06-27 14:12

I am unclear on what needs to be changed.

Does the FindCuda package need to require the C compiler to be enabled only for non Visual Studio generators? Or should we just require the C compiler no matter what to be safe?

If that happens we just need to change the non Visual Studio branch to use the REAL path for the C compiler and we are good, correct?
(0036272)
James Bigler (developer)
2014-06-27 14:19

There are two issues here.

1. CUDA needs a C compiler. If you have projects that are *only* cuda files, then CMake gets confused, because FindCUDA sets the language of the target to C (or CXX) without CMake ever setting up the C compiler.

2. FindCUDA also needs the path to the true path to C compiler. This needs to be done in different ways based on whether you are using VS or not.
(0036273)
Adam Strzelecki (reporter)
2014-06-27 15:16

Okay I think we shouldn't specify explicitly C compiler unless there one enabled. NVCC does not need C compiler to be specified explicitly and picks up the default one.

Frankly I dunno why -ccbin is forced in first place but the original author of this module, since NVCC works fine without that in most of the cases.
(0036274)
Adam Strzelecki (reporter)
2014-06-27 15:51

Atttached 0002 patch which skips -ccbin when C language is not enabled at all (except if is is visual studio), otherwise C compiler is dereferenced (if it is symlink).
(0036275)
James Bigler (developer)
2014-06-27 15:53

There are several reason why -ccbin is specified.

1. For 64 bit builds in VS it was necessary, because for many years CUDA got confused. This might have gotten better, but I haven't investigated exactly what version is required to remove this.

2. When you aren't using the default compiler (the one in the path), you can get into situations where your host code is compiled with one version of the compiler and your CUDA code gets compiled with a different one. This can lead to bad times.

There might be other situations, but I can't remember them offhand.
(0036276)
Adam Strzelecki (reporter)
2014-06-27 15:55

Re 0014971:0036275: This should be taken into account with 0002 patch, since it applies only to non VC builds, and only when C compiler is enabled, so if custom one is set then it should be all fine. Also it takes always into account that user may set actually CMAKE_C_COMPILER via -D and it will pick it up.
(0036277)
James Bigler (developer)
2014-06-27 16:02

I would like this part of the commit message added to the comment, so that it is more clear why this check for CMAKE_C_COMPILER is done.

Also we need to check whether CMAKE_C_COMPILER is defined at all otherwise skip
-ccbin and let nvcc use its own default C compiler.

Also try and prefix any local variables with cuda or __cuda (see c_compiler_realpath). You can't be sure that the value of this variable is unset and you could set CUDA_C_COMPILER to whatever the previous value is. Alternatively you can set c_compiler_realpath to nothing before the if block. Man, I wish we had local variables outside of functions.
(0036278)
Adam Strzelecki (reporter)
2014-06-27 16:22

Re 0014971:0036277: Thanks for instant feedback!

Please find attached 0003 version with slightly reworded commit message and sanitized c_compiler_realpath variable in case it is set in PARENT scope. I have not used cuda prefix intentionally since this compiler (1) isn't part of CUDA, but it is just used by CUDA, (2) anyway this variable is changed locally (unless used with PARENT_SCOPE) as far I understand CMake workflow correct.
(0036280)
Robert Maynard (manager)
2014-06-27 17:23

I have merged 0003 to cmake next
(0036281)
James Bigler (developer)
2014-06-27 17:57

I was hoping the part in the comment message that describes why the check for CMAKE_C_COMPILER is done would have made it into a comment in FindCUDA.cmake where the check was done.

Something like:

+ # Using cc which is symlink to clang may let NVCC think it is GCC and issue
+ # unhandled -dumpspecs option to clang. Also in case neither
+ # CMAKE_C_COMPILER is defined (project does not use C language) nor
+ # CUDA_HOST_COMPILER is specified manually we should skip -ccbin and let
+ # nvcc use its own default C compiler.

When developing code, it is more helpful to have this information in the comment rather than buried in a commit message somewhere.
(0036282)
Robert Maynard (manager)
2014-06-27 18:01

I will update the commit to add a comment to FindCuda on the check for CMAKE_C_COMPILER on Monday.
(0039432)
Axel Huebl (reporter)
2015-09-17 08:04

Just a note on the issue since the resolution is still marked as "open" in the issue tracker.

This issue was fixed by the applied patch in the CMake 3.1.0 release.
  https://github.com/Kitware/CMake/commit/32bcec5fab8a92590bfc2efafe29f2403bbab4dd#diff-4740178b5defb85b802090e7f04ae7e2 [^]

Unfortunately, it introduces a bug with all environments that expect that the symlink for the host compiler (`ABSOLUTE` vs `REALPATH` in `get_filename_component`) is *not* resolved (e.g., common on Cray HPC systems).

This follow-up issue in turn is now fixed in `master` since
  https://github.com/Kitware/CMake/commit/b405f01daaeaeda98d448e2f0d71ea685757a5bd#diff-4740178b5defb85b802090e7f04ae7e2 [^]

but has not yet reached a stable release (bug is still in the latest release as of CMake 3.3.1)
(0042566)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2014-06-12 13:54 Adam Strzelecki New Issue
2014-06-12 13:54 Adam Strzelecki File Added: 0001-FindCUDA-Fix-compilation-with-Clang-on-OSX.patch
2014-06-12 14:01 Robert Maynard Note Added: 0036170
2014-06-12 14:01 Robert Maynard Assigned To => James Bigler
2014-06-12 14:01 Robert Maynard Status new => assigned
2014-06-12 14:06 Brad King Note Added: 0036171
2014-06-13 08:31 Adam Strzelecki Note Added: 0036182
2014-06-13 13:05 James Bigler Note Added: 0036196
2014-06-13 13:06 James Bigler Note Added: 0036197
2014-06-13 13:21 Brad King Note Added: 0036198
2014-06-13 13:33 James Bigler Note Added: 0036199
2014-06-13 13:49 Brad King Note Added: 0036200
2014-06-13 14:24 Adam Strzelecki Note Added: 0036201
2014-06-13 14:25 Adam Strzelecki Note Edited: 0036201
2014-06-13 14:27 Adam Strzelecki Note Edited: 0036201
2014-06-13 14:29 Adam Strzelecki Note Edited: 0036201
2014-06-13 14:30 Adam Strzelecki Note Deleted: 0036182
2014-06-13 14:43 James Bigler Note Added: 0036202
2014-06-13 14:44 James Bigler Note Edited: 0036202
2014-06-13 14:44 James Bigler Note Edited: 0036202
2014-06-13 14:44 James Bigler Note Edited: 0036202
2014-06-13 14:45 James Bigler Note Edited: 0036202
2014-06-26 04:25 Adam Strzelecki Note Added: 0036255
2014-06-26 16:27 James Bigler Assigned To James Bigler => Robert Maynard
2014-06-26 16:27 James Bigler Note Added: 0036262
2014-06-27 09:55 Brad King Note Added: 0036268
2014-06-27 12:46 James Bigler Note Added: 0036270
2014-06-27 14:12 Robert Maynard Note Added: 0036271
2014-06-27 14:19 James Bigler Note Added: 0036272
2014-06-27 15:16 Adam Strzelecki Note Added: 0036273
2014-06-27 15:49 Adam Strzelecki File Added: 0002-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch
2014-06-27 15:51 Adam Strzelecki Note Added: 0036274
2014-06-27 15:53 James Bigler Note Added: 0036275
2014-06-27 15:55 Adam Strzelecki Note Added: 0036276
2014-06-27 16:02 James Bigler Note Added: 0036277
2014-06-27 16:19 Adam Strzelecki File Added: 0003-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch
2014-06-27 16:22 Adam Strzelecki Note Added: 0036278
2014-06-27 17:23 Robert Maynard Note Added: 0036280
2014-06-27 17:57 James Bigler Note Added: 0036281
2014-06-27 18:01 Robert Maynard Note Added: 0036282
2015-09-17 08:04 Axel Huebl Note Added: 0039432
2016-06-10 14:29 Kitware Robot Note Added: 0042566
2016-06-10 14:29 Kitware Robot Status assigned => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team