<br>Part 1 - Being resent in brokendown form due to 40kb limit on mail list<br><br>Continuing on with my attempt to build a project with includes 3rdParty
Libs I have run into a problem when adding library (using
add_subdirectory( pathtowherever/dcmtk dcmtk ) dcmtk (Dicom Toolkit)
and building a CUDA test application (nbody - from NVIDA SDK) as test
to verity I could build both using CMake.<br>
<br>I have the following line in one of my CMakeLists.txt files which I have traced the issue down to. <br><div class="im"><br>add_subdirectory( ${THIRD_PARTY_SRC_DIR}/dcmtk-3.5.4 ./dcmtk-3.5.4 )<br><br></div>When I include this line the nbody app fails to build. When I remove it the NBody app compiles.<br>
<br>The link error created when dcmtk is included in the project is:<br><br>1>Linking...<br>1>bodysystemcuda.obj
: error LNK2019: unresolved external symbol allocateNBodyArrays
referenced in function "protected: virtual void __cdecl
BodySystemCUDA::_initialize(<div id=":232" class="ii gt">int)" (?_initialize@BodySystemCUDA@@MEAAXH@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
registerGLBufferObject referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_initialize(int)" (?_initialize@BodySystemCUDA@@MEAAXH@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
unregisterGLBufferObject referenced in function "protected: virtual
void __cdecl BodySystemCUDA::_finalize(void)" (?_finalize@BodySystemCUDA@@MEAAXXZ)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
deleteNBodyArrays referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_finalize(void)" (?_finalize@BodySystemCUDA@@MEAAXXZ)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
setDeviceSoftening referenced in function "public: virtual void __cdecl
BodySystemCUDA::setSoftening(float)" (?setSoftening@BodySystemCUDA@@UEAAXM@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
integrateNbodySystem referenced in function "public: virtual void
__cdecl BodySystemCUDA::update(float)" (?update@BodySystemCUDA@@UEAAXM@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayFromDevice referenced in function "public: virtual float *
__cdecl BodySystemCUDA::getArray(enum BodySystem::BodyArray)"
(?getArray@BodySystemCUDA@@UEAAPEAMW4BodyArray@BodySystem@@@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayToDevice referenced in function "public: virtual void __cdecl
BodySystemCUDA::setArray(enum BodySystem::BodyArray,float const *)"
(?setArray@BodySystemCUDA@@UEAAXW4BodyArray@BodySystem@@PEBM@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
threadSync referenced in function "public: virtual void __cdecl
BodySystemCUDA::synchronizeThreads(void)const " (?synchronizeThreads@BodySystemCUDA@@UEBAXXZ)<br>
1>C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.exe : fatal error LNK1120: 9 unresolved externals<br>1>Build log was saved at "file://c:\projects\NIH2009\source\branches\brian\build\dvip4-Win64-broken\cpp_source\app\nbody\nbody.dir\Debug\BuildLog.htm"<br>
1>nbody - 10 error(s), 0 warning(s)<br><br>Which
is a linker error where extern "C" files cannot be found. The
inclusion of a third party lib affects the project globally. Now
conversations above imply that CMake was never designed for this type
of use case. I have already had to change boost cmake build and will
be submitting my patch to that mailing list. It appears as though now
dcmtk does not play nice either. There are differences in the files...
some I expect and others I did not.<br>
<br>A simple file diff showing the files affected between just the
project with nbody (only nbody) and the project with dcmtk (nbody and
dcmtk) included are:<br><br>Files dvip4-Win64-working/ALL_BUILD.vcproj and dvip4-Win64-broken/ALL_BUILD.vcproj differ<br>
Files dvip4-Win64-working/CMakeCache.txt and dvip4-Win64-broken/CMakeCache.txt differ<br>Files dvip4-Win64-working/CMakeFiles/CMakeDetermineCompilerABI_C.bin and dvip4-Win64-broken/CMakeFiles/CMakeDetermineCompilerABI_C.bin differ<br>
Files dvip4-Win64-working/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin and dvip4-Win64-broken/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin differ<br>Files dvip4-Win64-working/CMakeFiles/generate.stamp.list and dvip4-Win64-broken/CMakeFiles/generate.stamp.list differ<br>
Only in dvip4-Win64-broken/CMakeFiles: INSTALL_force.rule<br>Files dvip4-Win64-working/CMakeFiles/TargetDirectories.txt and dvip4-Win64-broken/CMakeFiles/TargetDirectories.txt differ<br>Files dvip4-Win64-working/cpp_source/ALL_BUILD.vcproj and dvip4-Win64-broken/cpp_source/ALL_BUILD.vcproj differ<br>
Only in dvip4-Win64-broken/cpp_source/app/CMakeFiles: INSTALL_force.rule<br>Only in dvip4-Win64-broken/cpp_source/app/dicomserver/CMakeFiles: INSTALL_force.rule<br>Only in dvip4-Win64-broken/cpp_source/app/dicomserver: INSTALL.vcproj<br>
Only in dvip4-Win64-broken/cpp_source/app: INSTALL.vcproj<br><br>Only in dvip4-Win64-working/cpp_source/app/nbody: bodysystemcuda.linkinfo<br>Files dvip4-Win64-working/cpp_source/app/nbody/CMakeFiles/generate.stamp.depend and dvip4-Win64-broken/cpp_source/app/nbody/CMakeFiles/generate.stamp.depend differ<br>
Only in dvip4-Win64-broken/cpp_source/app/nbody/CMakeFiles: INSTALL_force.rule<br>Files dvip4-Win64-working/cpp_source/app/nbody/CMakeFiles/nbody_generated_bodysystemcuda.cu.obj.cmake and dvip4-Win64-broken/cpp_source/app/nbody/CMakeFiles/nbody_generated_bodysystemcuda.cu.obj.cmake differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/CMakeFiles/nbody_generated_bodysystemcuda.cu.obj.depend and dvip4-Win64-broken/cpp_source/app/nbody/CMakeFiles/nbody_generated_bodysystemcuda.cu.obj.depend differ<br>Files dvip4-Win64-working/cpp_source/app/nbody/Debug/nbody_generated_bodysystemcuda.cu.obj and dvip4-Win64-broken/cpp_source/app/nbody/Debug/nbody_generated_bodysystemcuda.cu.obj differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/Debug/nbody_generated_nbody_kernel.cu.obj and dvip4-Win64-broken/cpp_source/app/nbody/Debug/nbody_generated_nbody_kernel.cu.obj differ<br>Only in dvip4-Win64-broken/cpp_source/app/nbody: INSTALL.vcproj<br>
Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/bodysystemcpu.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/bodysystemcpu.obj differ<br>Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/bodysystemcuda.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/bodysystemcuda.obj differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/BuildLog.htm and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/BuildLog.htm differ<br>Only in dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug: mt.dep<br>
Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/nbody.exe.embed.manifest and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/nbody.exe.embed.manifest differ<br>Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/nbody.exe.embed.manifest.res and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/nbody.exe.embed.manifest.res differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/nbody.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/nbody.obj differ<br>Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/nbody_gold.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/nbody_gold.obj differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/param.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/param.obj differ<br>Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/paramgl.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/paramgl.obj differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/nbody.dir/Debug/render_particles.obj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.dir/Debug/render_particles.obj differ<br>Files dvip4-Win64-working/cpp_source/app/nbody/nbody.vcproj and dvip4-Win64-broken/cpp_source/app/nbody/nbody.vcproj differ<br>
Files dvip4-Win64-working/cpp_source/app/nbody/vc90.pdb and dvip4-Win64-broken/cpp_source/app/nbody/vc90.pdb differ<br><br>Only in dvip4-Win64-broken/cpp_source/CMakeFiles: INSTALL_force.rule<br>Files dvip4-Win64-working/cpp_source/dvip4src.sln and dvip4-Win64-broken/cpp_source/dvip4src.sln differ<br>
Only in dvip4-Win64-broken/cpp_source: INSTALL.vcproj<br>Files dvip4-Win64-working/cpp_source/lib/cmake_install.cmake and dvip4-Win64-broken/cpp_source/lib/cmake_install.cmake differ<br>Only in dvip4-Win64-broken/cpp_source/lib/CMakeFiles: INSTALL_force.rule<br>
Only in dvip4-Win64-broken/cpp_source/lib: dcmtk-3.5.4<br>Only in dvip4-Win64-broken/cpp_source/lib: INSTALL.vcproj<br>Files dvip4-Win64-working/dvip4.ncb and dvip4-Win64-broken/dvip4.ncb differ<br>Files dvip4-Win64-working/dvip4.sln and dvip4-Win64-broken/dvip4.sln differ<br>
Files dvip4-Win64-working/dvip4.suo and dvip4-Win64-broken/dvip4.suo differ<br>Only in dvip4-Win64-broken: INSTALL.vcproj<br>Only in dvip4-Win64-broken: INSTALL.vcproj.MEDPHYSICS.bdavis.user<br>Files dvip4-Win64-working/ZERO_CHECK.vcproj and dvip4-Win64-broken/ZERO_CHECK.vcproj differ<br>
<br><br>The differences I was not expecting relate to the dvip4-Win64-working/cpp_source/app/nbody
directory. There are differences due to changes in the GUID for visual
studio and random batch file names which I expect. Changes which
affect the build settings I did not. I put a line feeds above between
the section (nbody) I was expecting no changes (other than GUIDS and
file names for batch files etc)<br>
<br>I sent an email which further details the process to build nbody titled:<br><br>"CUDA, CMAKE, and an attempt to build nbody"<br><br>but
it is awaiting moderator approval due to it's size. There is some good
stuff in this email relating to building nbody and my experience in
doing so. This is email is meant to document the issues when including
a 3rdParty library and having global build setting craziness ensue.
This was one of the issues encountered when building nbody.<br>
<br>Some files are missing? Which I did not expect:<br>bodysystemcuda.linkinfo<br>INSTALL_force.rule (Artificial dependency for a custom command.) - of course what else would it be?<br>INSTALL.vcproj
(Contains actual project configuration, but this seems to shift around
in the project based on where actual projects are)<br>
mt.dep<br><br><br>... to be continued<br><br><br></div>