MantisBT - CMake
View Issue Details
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
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch 0001-FindCUDA-Fix-compilation-with-Clang-on-OSX.patch (1,736) 2014-06-12 13:54
https://public.kitware.com/Bug/file/5163/0001-FindCUDA-Fix-compilation-with-Clang-on-OSX.patch
patch 0002-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch (3,521) 2014-06-27 15:49
https://public.kitware.com/Bug/file/5178/0002-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch
patch 0003-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch (3,632) 2014-06-27 16:19
https://public.kitware.com/Bug/file/5179/0003-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch
Issue History
Date ModifiedUsernameFieldChange
2014-06-12 13:54Adam StrzeleckiNew Issue
2014-06-12 13:54Adam StrzeleckiFile Added: 0001-FindCUDA-Fix-compilation-with-Clang-on-OSX.patch
2014-06-12 14:01Robert MaynardNote Added: 0036170
2014-06-12 14:01Robert MaynardAssigned To => James Bigler
2014-06-12 14:01Robert MaynardStatusnew => assigned
2014-06-12 14:06Brad KingNote Added: 0036171
2014-06-13 08:31Adam StrzeleckiNote Added: 0036182
2014-06-13 13:05James BiglerNote Added: 0036196
2014-06-13 13:06James BiglerNote Added: 0036197
2014-06-13 13:21Brad KingNote Added: 0036198
2014-06-13 13:33James BiglerNote Added: 0036199
2014-06-13 13:49Brad KingNote Added: 0036200
2014-06-13 14:24Adam StrzeleckiNote Added: 0036201
2014-06-13 14:25Adam StrzeleckiNote Edited: 0036201bug_revision_view_page.php?bugnote_id=36201#r1478
2014-06-13 14:27Adam StrzeleckiNote Edited: 0036201bug_revision_view_page.php?bugnote_id=36201#r1479
2014-06-13 14:29Adam StrzeleckiNote Edited: 0036201bug_revision_view_page.php?bugnote_id=36201#r1480
2014-06-13 14:30Adam StrzeleckiNote Deleted: 0036182
2014-06-13 14:43James BiglerNote Added: 0036202
2014-06-13 14:44James BiglerNote Edited: 0036202bug_revision_view_page.php?bugnote_id=36202#r1486
2014-06-13 14:44James BiglerNote Edited: 0036202bug_revision_view_page.php?bugnote_id=36202#r1487
2014-06-13 14:44James BiglerNote Edited: 0036202bug_revision_view_page.php?bugnote_id=36202#r1488
2014-06-13 14:45James BiglerNote Edited: 0036202bug_revision_view_page.php?bugnote_id=36202#r1489
2014-06-26 04:25Adam StrzeleckiNote Added: 0036255
2014-06-26 16:27James BiglerAssigned ToJames Bigler => Robert Maynard
2014-06-26 16:27James BiglerNote Added: 0036262
2014-06-27 09:55Brad KingNote Added: 0036268
2014-06-27 12:46James BiglerNote Added: 0036270
2014-06-27 14:12Robert MaynardNote Added: 0036271
2014-06-27 14:19James BiglerNote Added: 0036272
2014-06-27 15:16Adam StrzeleckiNote Added: 0036273
2014-06-27 15:49Adam StrzeleckiFile Added: 0002-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch
2014-06-27 15:51Adam StrzeleckiNote Added: 0036274
2014-06-27 15:53James BiglerNote Added: 0036275
2014-06-27 15:55Adam StrzeleckiNote Added: 0036276
2014-06-27 16:02James BiglerNote Added: 0036277
2014-06-27 16:19Adam StrzeleckiFile Added: 0003-FindCUDA-Fix-OSX-Clang-no-C-language-enabled.patch
2014-06-27 16:22Adam StrzeleckiNote Added: 0036278
2014-06-27 17:23Robert MaynardNote Added: 0036280
2014-06-27 17:57James BiglerNote Added: 0036281
2014-06-27 18:01Robert MaynardNote Added: 0036282
2015-09-17 08:04Axel HueblNote Added: 0039432
2016-06-10 14:29Kitware RobotNote Added: 0042566
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0036170)
Robert Maynard   
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   
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   
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   
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   
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   
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   
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   
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   
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   
2014-06-26 04:25   
Re 0014971:0036202

Any news whether this will be merged anytime soon?
(0036262)
James Bigler   
2014-06-26 16:27   
Robert, you can merge this in provided the changes I suggested are put into place.
(0036268)
Brad King   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
2014-06-27 17:23   
I have merged 0003 to cmake next
(0036281)
James Bigler   
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   
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   
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   
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.