MantisBT - CMake
View Issue Details
0012198CMakeCMakepublic2011-05-17 08:512016-06-10 14:31
Denis Shamonin 
James Bigler 
highmajoralways
closedmoved 
WindowsWindows 7 (64 bit)
CMake 2.8.4 
 
0012198: FindCUDA.cmake, INCLUDE_DIRECTORIES, The command line is too long.
Hello,

1. I am posting it to CMake bug tracker because original creators of FindCUDA.cmake
James Bigler and Abe Stephens not willing to support it according to http://www.cmake.org/pipermail/cmake/2010-January/034322.html [^]

2. Development tools:
Visual Studio 2008
CMake 2.8.4
CUDA Toolkit 3.2 stable release (64 bit)
ITK 4.0.0

3. I've created the simple library with only 2 files in it (see CUDA_lib_test.zip) .
This library also includes ITK4 with FIND_PACKAGE( ITK REQUIRED )

4. Problem:
Therefore we have some issues with FindCUDA.cmake module.
When we start the compilation we see the following call to NVidia compiler
(see nvcc_call.txt inside of CUDA_lib_test.zip)

This call looks very strange to us.
Why would you need to pass all include directories from entire solution to NVidia compiler?
I could understand that you would like to provide include directories for the
ncvv.exe -Xcompiler option. But probably in more specific and controlled way.
I've studied this problem a bit and found that this is happens because of the CMake call:

  get_directory_property(CUDA_NVCC_INCLUDE_DIRECTORIES INCLUDE_DIRECTORIES) at line 890: FindCUDA.cmake
  if(CUDA_NVCC_INCLUDE_DIRECTORIES)
    foreach(dir ${CUDA_NVCC_INCLUDE_DIRECTORIES})
      list(APPEND CUDA_NVCC_INCLUDE_ARGS "-I${dir}")
    endforeach()
  endif()

Do you mean the CUDA_INCLUDE_DIRECTORIES instead of INCLUDE_DIRECTORIES?
So as a temp solution we commented this part of FindCUDA.cmake.

The question is how to control or disable the directories to be passed to NVidia compiler?

As a result of this long ITK include directories list NVidia compiler could not be executed on Windows platform.
Ending with system error:

1>The command line is too long.
1>CMake Error at CMakeFiles/CUDA_lib_test_generated_bicubicTexture.cu.obj.cmake:198 (message):
1> Error generating
1> D:/tests/CUDA_lib_test/build/Debug/CUDA_lib_test_generated_bicubicTexture.cu.obj
1>Project : error PRJ0019: A tool returned an error code from "Building NVCC (Device) object Debug/CUDA_lib_test_generated_bicubicTexture.cu.obj"
1>Build log was saved at "file://d:\tests\CUDA_lib_test\build\CUDA_lib_test.dir\Debug\BuildLog.htm" [^]
1>CUDA_lib_test - 1 error(s), 0 warning(s)

5. As a part of this problem I don see why c++ compiler flags like (-DITK_IO_FACTORY_REGISTER_MANAGER or -D_SCL_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -

D_CRT_TIME_FUNCTIONS_NO_DEPRECATE) are propagated to NVidia ncvv.exe compiler and not to -Xcompiler? (see nvcc_call.txt inside of CUDA_lib_test.zip)

I think that is another error in FindCUDA.cmake.

Could you please fix it or recommend the solution for this problems.

Thank you,
-Denis.
No tags attached.
related to 0014094closed Robert Maynard FindCUDA: Marco CUDA_WRAP_SRCS does not de-duplicate entries in CUDA_NVCC_INCLUDE_DIRECTORIES 
zip CUDA_lib_test.zip (13,953) 2011-05-17 08:51
https://public.kitware.com/Bug/file/3879/CUDA_lib_test.zip
Issue History
2011-05-17 08:51Denis ShamoninNew Issue
2011-05-17 08:51Denis ShamoninFile Added: CUDA_lib_test.zip
2011-05-17 08:55Alexey OzeritskyAssigned To => Alexey Ozeritsky
2011-05-17 08:55Alexey OzeritskyStatusnew => assigned
2011-05-17 12:57James BiglerNote Added: 0026517
2011-05-18 03:44Denis ShamoninNote Added: 0026540
2011-05-18 11:32James BiglerNote Added: 0026541
2011-05-18 11:33Alexey OzeritskyAssigned ToAlexey Ozeritsky =>
2011-05-18 11:33Alexey OzeritskyStatusassigned => new
2011-06-21 09:03Dzenan ZukicNote Added: 0026935
2011-06-21 16:16James BiglerNote Added: 0026942
2011-06-21 16:16James BiglerAssigned To => James Bigler
2011-06-21 16:16James BiglerStatusnew => assigned
2011-07-20 04:06Dzenan ZukicNote Added: 0027055
2012-01-20 03:34Marius StaringNote Added: 0028370
2012-01-20 03:51Marius StaringNote Added: 0028371
2012-01-20 12:11James BiglerNote Added: 0028381
2012-01-24 03:48Marius StaringNote Added: 0028399
2012-10-25 04:14Marius StaringNote Added: 0031310
2013-04-17 04:11Marcel LooseRelationship addedrelated to 0014094
2016-06-10 14:28Kitware RobotNote Added: 0041840
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0026517)
James Bigler   
2011-05-17 12:57   
I never said I wasn't supporting FindCUDA in that email thread. I only said I wasn't going to add support for getting stuff out of the NVIDIA SDK. The SDK was never meant to be used externally, unlike the Toolkit (which I do support).

Now on to your other points.

We use INCLUDE_DIRECTORIES, because this is the least surprising behavior to users. It became tiresome to have to do the following all over the place. It was more convenient to simply use the same includes as the regular host code.

include_directories(${stuff})
cuda_include_directories(${stuff})

Also only specifying include directories with -Xcompiler won't work as well as you might think, because of how nvcc processes the files in multiple stages. This is also true for the -D flags, because these are used during preprocessing and not just when code is actually compiled by the host compiler.

As to the long command line, how does the rest of CMake handle the long command lines?
(0026540)
Denis Shamonin   
2011-05-18 03:44   
Hi,
That is nice that you still support it.
According to http://support.microsoft.com/kb/830473 [^]
The maximum length of the string that you can use at the command prompt is 8191 characters.
This test call is 8467 characters, so it will fail. I've made this call deliberately to test entire includes in case you want to create ITK4+CUDA.
Similar to http://www.vtk.org/Wiki/ITK_Release_4/GPU_Acceleration [^]

I' am not sure how CMake deal with it. I the following thread, Brad says something about hitting the limits with object files.
http://www.cmake.org/pipermail/cmake/2008-October/024621.html [^]
(0026541)
James Bigler   
2011-05-18 11:32   
I wonder if we might be able to work around this, by removing duplicate include paths. Is there any redundancy in your includes? I know this doesn't address the underlying issue. I'll have to look at this response file thing mentioned in the email.
(0026935)
Dzenan Zukic   
2011-06-21 09:03   
Hey, I would like to vote for fixing this issue too. ITK4's release is coming closer, and a lot more people will start hitting this bug.

Here is the description of my case (Denis' is shorter and better):
http://old.nabble.com/CUDA-compile-error-when-switching-from-ITK-3.20-to-4-Git%3A-%22The-command-line-is-too-long%22-td31739802.html [^]
(0026942)
James Bigler   
2011-06-21 16:16   
OK, so I just did a little inspection. It appears that nvcc can take an options file (it had to be the very last entry after reading all the others. ;)

--options-file <file>,... (-optf)
        Include command line options from specified file.

Of course, doing this will require a bit of effort to fix, because I'll have to think about the best way to handle this.

FindCUDA already configures a cmake script (run_cuda.cmake) during configuration for each file. This script does a myriad of things. Perhaps the easiest thing to do would be to generate the options file as an early phase in the script and then use that. Yeah, that seems like the way to go.
(0027055)
Dzenan Zukic   
2011-07-20 04:06   
This bug is still present in 2.8.5. Same error message as before:

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------
2>------ Build started: Project: Spine, Configuration: Debug x64 ------
2> Building NVCC (Device) object Debug/Spine_generated_LHstuff.cu.obj
2> The command line is too long.
2> CMake Error at CMakeFiles/Spine_generated_LHstuff.cu.obj.cmake:198 (message):
2> Error generating D:/Repo/Spine/Debug/Spine_generated_LHstuff.cu.obj
2>
2>
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
3>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug x64 ------
3>Project not selected to build for this solution configuration
========== Build: 1 succeeded, 1 failed, 1 up-to-date, 1 skipped ==========
(0028370)
Marius Staring   
2012-01-20 03:34   
The bug is still present in 2.8.7.

Is anyone working on this?
(0028371)
Marius Staring   
2012-01-20 03:51   
The workaround to install ITK4 and build my program against the installed version also does not work anymore. The command line is still too long.

This effectively means that ITK4 cannot be used with CUDA.

Maybe a developer can increase the severity of this bug to blocker.
(0028381)
James Bigler   
2012-01-20 12:11   
No one responded to one of my questions:

Is there any redundancy in your includes?
(0028399)
Marius Staring   
2012-01-24 03:48   
Dear James,

Sorry for that.

If you open the attached CUDA_lib_test.zip there is a file called nvcc_call.txt. It contains the full command line call to nvcc. You can see that all directories and subdirectories of the ITK modules are included. Because there are quite a number of those modules, the command line is really long. There are no (sub)directories listed twice, so there is no redundancy in that sense.

Maybe there is a recursive include, which then can just point to the ITK4/Modules directory ?

Regards, Marius
(0031310)
Marius Staring   
2012-10-25 04:14   
Dear all,

Cory Quammen has found a workaround by including the following line to the CMake list of the directory containing the CUDA kernels:

SET_DIRECTORY_PROPERTIES( PROPERTIES INCLUDE_DIRECTORIES "" )

It simply removes the ITK includes, thereby reducing the command line length.

Elastix now compiles with CUDA again.

Regards, Marius
(0041840)
Kitware Robot   
2016-06-10 14:28   
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.