<br>Part 2 - continued from above<br><br><begin rant - skip this if not interested><br>Now finding where allocateNBodyArrays is in the files should not be hard, but then again I am suing Win7. On a REAL os I would use grep. In the search bar in Win7 I type in allocateNBodyArrays and search NVIDIA SDK and I wait for Win7 to allow me to select find in files (why this is not an option in the first place is anyone's guess) and it returns bodysystemcuda.cpp but not <a href="http://bodysystemcuda.cu">bodysystemcuda.cu</a>. And here is where you gotta love Win7. So I search all of C: find in files. On a 500 gig drive this takes a while. There is hope at first when the status bar cruises along to 50% (going through indexed locations) then the status bar goes to an exponentially decaying speed. At this point all hope is lost at finding it in the next centry with Win7. Not only that, but all the windows Lock up at about 99% or so (about the time the status bar reaches the recycle arrows on the path bar/search status bar). I can Alt->ctrl->del and launch task manager which never appears. I can tab between windows, but they are unresponsive. I then hard reboot the system. "My Idea for Win7 is to have a DO_NOT_SUCK_FLAG to be passed at boot time". Lets see if MS can implement that one.<br>
<br>Cygwin grep also does not work. And after installing Cygwin worked for about a week and now startx script crashes just before flashing 3 dos command windows before giving up the show. "I'm a PC... with Windows, but not by choice"<br>
<end rant><br><br>This can be found using eclipse or visual studio which can search .cu files<br><br>Above errors are due to code in <a href="http://bodysystemcuda.cu">bodysystemcuda.cu</a>:<br><br><br>extern "C"<br>
{<br><br>void setDeviceSoftening(float softening)<br>{<br> float softeningSq = softening*softening;<br><br> cutilSafeCall(cudaMemcpyToSymbol("softeningSquared", &softeningSq,<br> sizeof(float), 0,<br>
cudaMemcpyHostToDevice));<br>}<br><br>void allocateNBodyArrays(float* vel[2], int numBodies)<br>{<br> // 4 floats each for alignment reasons<br> unsigned int memSize = sizeof( float) * 4 * numBodies;<br>
<br> cutilSafeCall(cudaMalloc((void**)&vel[0], memSize));<br> cutilSafeCall(cudaMalloc((void**)&vel[1], memSize));<br>}<br>...<br>...<br>}<br><br>and code in bodysystemcuda.cpp:<br><br>extern "C"<br>
{<br> void cudaInit(int argc, char **argv);<br> void setDeviceSoftening(float softening);<br> void allocateNBodyArrays(float* vel[2], int numBodies);<br> void deleteNBodyArrays(float* vel[2]);<br>...<br>...<br>
}<br><br>So I begin checking build settings (below are the important parts) and comparing between NVIDIA and CMAKE<br><br>NVIDIA:<br><br>/OUT:"../../bin/win64/Debug/nbody.exe"<br>/INCREMENTAL:NO<br>/LIBPATH:"C:\CUDA\lib"<br>
/LIBPATH:"../../common/lib"<br>/MANIFEST<br>/MANIFESTFILE:"x64\Debug\nbody.exe.intermediate.manifest"<br>/MANIFESTUAC:"level='asInvoker' uiAccess='false'"<br>/DEBUG<br>/PDB:"x64\Debug/nbody.pdb"<br>
/SUBSYSTEM:CONSOLE<br>/DYNAMICBASE:NO<br>/MACHINE:X64<br>cudart.lib cutil64D.lib glew64.lib glut64.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib<br>
<br>CMAKE:<br><br>/OUT:"C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.exe"<br>/VERSION:0.0<br>/INCREMENTAL<br>/LIBPATH:"C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib\Debug"<br>
/LIBPATH:"C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib"<br>/MANIFEST<br>/MANIFESTFILE:"nbody.dir\Debug\nbody.exe.intermediate.manifest"<br>/MANIFESTUAC:"level='asInvoker' uiAccess='false'"<br>
/DEBUG<br>/PDB:"C:/projects/NIH2009/source/branches/brian/build/Windows-6.1/ouput/bin/Debug/nbody.pdb"<br>/SUBSYSTEM:CONSOLE<br>/DYNAMICBASE<br>/NXCOMPAT<br>/IMPLIB:"C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.lib" <br>
/machine:x64<br>/debug kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib C:\CUDA\lib\cudart.lib C:\CUDA\lib\cuda.lib C:\CUDA\lib\cudart.lib "C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib\cutil64D.lib" "C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib\glew64.lib" "C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib\glut64.lib"<br>
<br>So I point CMake to just my CMakeLists.txt file for my nbody project, not the upperlevel CMakeLists.txt file which add_subdirectory the nbody CMakeList.txt file.<br><br>What I get is an executable and the follwoing text when it is run (answer to why it compiled is forthcoming):<br>
<br>"The application has failed to start because its side-by-side configuration is incorrect. Please see<br>the application event log or use the command-line sxstrace.exe tool for more detail."<br><br>Anyone who has seen this error has to appreciate the obscurity that is Windows. Translated: "I can't find my DLLs"<br>
So I launch in as Administrator by (right clicking the command window Icon - <begin rant> must be done from start menu as we sure would'nt want this feature/option at the "Pined" Icons on the task bar <end rant>) and I preform the following:<br>
<br><br>C:\Windows\system32>cd C:\projects\NIH2009\source\branches\brian\build\nbody\Debug<br><br>C:\projects\NIH2009\source\branches\brian\build\nbody\Debug>sxstrace<br>WinSxs Tracing Utility.<br>Usage: SxsTrace [Options]<br>
Options:<br> Trace -logfile:FileName [-nostop]<br> Enabling tracing for sxs.<br> Tracing log is saved to FileName.<br> If -nostop is specified, will not prompt to stop tracing.<br> Parse -logfile:FileName -outfile:ParsedFile [-filter:AppName]<br>
Translate the raw trace file into a human readable format and save the result to ParsedFile.<br> Use -filter option to filter the output.<br> Stoptrace<br> Stop the trace if it is not stopped before.<br>
Example: SxsTrace Trace -logfile:SxsTrace.etl<br> SxsTrace Parse -logfile:SxsTrace.etl -outfile:SxsTrace.txt<br><br>C:\projects\NIH2009\source\branches\brian\build\nbody\Debug> SxsTrace Trace -logfile:SxsTrace.etl<br>
Tracing started. Trace will be saved to file SxsTrace.etl.<br>Press Enter to stop tracing...<br><br><br>I then run nbody.exe and then I do:<br><br><br>C:\projects\NIH2009\source\branches\brian\build\nbody\Debug>SxsTrace Parse -logfile:SxsTrace.etl -ou<br>
tfile:SxsTrace.txt<br>Parsing log file SxsTrace.etl...<br>Parsing finished! Output saved to file SxsTrace.txt.<br><br>Which gives me in SxsTrace (<begin rant>why MS has to take a good idea, strace, and turn it into this convoluted process of convolution is anyone's guess <end rant>):<br>
<br>=================<br>Begin Activation Context Generation.<br>Input Parameter:<br> Flags = 0<br> ProcessorArchitecture = AMD64<br> CultureFallBacks = en-US;en<br> ManifestPath = C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\nbody.exe<br>
AssemblyDirectory = C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\<br> Application Config File =<br>-----------------<br>INFO: Parsing Manifest File C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\nbody.exe.<br>
INFO: Manifest Definition Identity is (null).<br> INFO: Reference: Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"<br>
INFO: Resolving reference Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".<br> INFO: Resolving reference for ProcessorArchitecture amd64.<br>
INFO: Resolving reference for culture Neutral.<br> INFO: Applying Binding Policy.<br> INFO: No publisher policy found.<br> INFO: No binding policy redirect found.<br> INFO: Begin assembly probing.<br>
INFO: Did not find the assembly in WinSxS.<br> INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_64\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.<br>
INFO: Attempt to probe manifest at C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT.DLL.<br> INFO: Attempt to probe manifest at C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT.MANIFEST.<br>
INFO: Attempt to probe manifest at C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.DLL.<br> INFO: Attempt to probe manifest at C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.MANIFEST.<br>
INFO: Did not find manifest for culture Neutral.<br> INFO: End assembly probing.<br> ERROR: Cannot resolve reference Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".<br>
ERROR: Activation Context generation failed.<br>End Activation Context Generation.<br><br><br>And here is where the developer learns of MS Manifesto files.<br><br>Now an answer to why it compiled in the first place: Default Build settings were overrided in CMakeLists.txt file above (in upper level directory) project file for nbody. I have an opinion (yea I know doesn't everyone) as to the logic of linking project build settings to directory hierarchy. Why relate one abstract thing, directory structure, to another abstract thing, project settings. This can cause the developer to layout their directory structure so that it plays nice with the build tool. Which ok may not be a bad thing, but the two should kept separate. Bjam did the same thing and I always questioned the logic of this. At least BJam (and maybe CMake as well - I did try this and ran into the CMake policy issue) allowed to put project files out on leaves of the trees instead of at branches for example:<br>
<br>At branches:<br>project->Jamfile.v2<br>project->subDir1->Jamfile.v2<br>project-->subDir2->subDir2->Jamfile.v2<br><br>At Leaves<br>project->build->Jamfile.v2<br>project->subDir1->build->Jamfile.v2<br>
project-->subDir2->subDir2->build->Jamfile.v2<br><br>Then project settings could be inherited through specification of inherited projects not by inherited directory structure of Jamfiles as the inheritance structure was broken by the Leaf ends. Is there such a thing as Project Inheritance specification within CMake?<br>
<br>There were some great things about BJam in this regard:<br>1) project structure could be made completely independent from directory structure.<br>2) Projects and settings could be inherited through specification.<br>3) The project specification could completely remap the build directory structure, see CMake Policy reference below:<br>
<br>For instance when I change:<br><br>add_subdirectory( source/cpp cpp_source )<br><br>to:<br><br>add_subdirectory( source/cpp ./ )<br><br>I get:<br><br>CMake Warning (dev) at CMakeLists.txt:128 (add_subdirectory):<br> Policy CMP0013 is not set: Duplicate binary directories are not allowed.<br>
Run "cmake --help-policy CMP0013" for policy details. Use the cmake_policy<br> command to set the policy and suppress this warning.<br><br> The binary directory<br><br> C:/projects/NIH2009/source/branches/brian/build/dvip4-Win64<br>
<br> is already used to build a source directory. This command uses it to build<br> source directory<br><br> C:/projects/NIH2009/source/branches/brian/source/cpp<br><br> which can generate conflicting build files. CMake does not support this<br>
use case but it used to work accidentally and is being allowed for<br> compatibility.<br>This warning is for project developers. Use -Wno-dev to suppress it.<br><br>FULL_FILE_PATH = platform/3rdParty/Win32/dcmtk/dcmtk-3.5.4.zip<br>
UNPACK_DIRECTORY = source/cpp/lib/3rdParty/Win32<br><br><br><br>Well that was my experience, some issues with Win7, some issues with CMake, and some issues with me not understanding what CMake does and doesn't do.<br>