Operating system: windows 10
Slicer version: 4
Expected behavior: Should build successfully
Actual behavior: Build failure .
I am new to 3D slicer , I installed on tools required and checked out sources from Github.
I configured the project using Cmake gui.
Source Path :F:/KS/Slicer
Build Path : F:/KS/Slicer-SuperBuild-Debug
After opening .sln file and building ALL_BUILD , I am getting several errors
First few errors are
Correct .
The Qt ver 5.13.0
First error
Error MSB6006 “cmd.exe” exited with code 1. python-PyGithub C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets 171
I don’t remember seeing such an error. Since this message only indicates that python-PyGithub build failed but does not contain the actual error message, we cannot do much. You need to find the error message printed by this subproject. Try to build just this subproject and have a look at all the most recently modified files in all the build folders to find the relevant log file (probably .log or .txt file).
Build paths as long as “F:\KS\Slicer-Superbuild-Debug” are known to cause various build issues. Retry the build from scratch, putting source code in F:\S4 and build in F:\S4D.
If you build Slicer using Qt that was built without SSL (I think Qt binaries that you download from Qt installer are built without SSL) then you may need to disable SSL support when you configure your Slicer build in CMake.
You can search for CMake variables by name in CMake GUI. To disable SSL, configure top-level build with Slicer_USE_PYTHONQT_WITH_OPENSSL set to OFF. But first just try to build Slicer in a shorter path (F:\S4, F:\S4D).
Thanks , Now I am getting less errors . Ilisted down 1st error and few warnings.
Now these are the link errors
Error LNK1120 24 unresolved externals [F:\KS\Slicer-SuperBuild-Debug\python-build\CMakeBuild\extensions\extension_hashlib\extension_hashlib.vcxproj] python F:\KS\Slicer-SuperBuild-Debug\python-build\Lib\lib-dynload\Release_hashlib.pyd 1
Warning LNK4098 defaultlib ‘MSVCRTD’ conflicts with use of other libs; use /NODEFAULTLIB:library [F:\KS\Slicer-SuperBuild-Debug\python-build\CMakeBuild\extensions\extension_binascii\extension_binascii.vcxproj] python F:\KS\Slicer-SuperBuild-Debug\LINK 1
Warning LNK4098 defaultlib ‘MSVCRTD’ conflicts with use of other libs; use /NODEFAULTLIB:library [F:\KS\Slicer-SuperBuild-Debug\python-build\CMakeBuild\extensions\extension_bz2\extension_bz2.vcxproj] python F:\KS\Slicer-SuperBuild-Debug\LINK 1
Warning LNK4272 library machine type ‘X86’ conflicts with target machine type ‘x64’ [F:\KS\Slicer-SuperBuild-Debug\python-build\CMakeBuild\extensions\extension_hashlib\extension_hashlib.vcxproj] python F:\KS\Slicer-SuperBuild-Debug\OpenSSL-install\Release\lib\ssleay32.lib 1
Warning LNK4272 library machine type ‘X86’ conflicts with target machine type ‘x64’ [F:\KS\Slicer-SuperBuild-Debug\python-build\CMakeBuild\extensions\extension_hashlib\extension_hashlib.vcxproj] python F:\KS\Slicer-SuperBuild-Debug\OpenSSL-install\Release\lib\libeay32.lib 1
Build paths as long as “F:\KS\Slicer-Superbuild-Debug” are known to cause various build issues. Retry the build from scratch, putting source code in F:\S4 and build in F:\S4D.
50 character limit is not accurate (especially since VTK modularization, which dramatically increased number of include directories). I’ve updated the build instructions to recommend limiting the source and build directory path lengths to 10 characters.
Since it is hard to reliably warn developer, should we just remove the PreventDirWithTooManyChars module and only rely on the documentation ?
I am also wondering if the generated solutions files (or makefile, ninja file) could be analyzed after configuration to detect use of long command line and long path.
There are a couple of different things that may fail with long paths. It would be very hard to detect them all.
Instead, we could fix many issues by installing VTK and ITK and use that install tree from Slicer. It would reduce the number of include and library directories, so command lines would less likely to become too long. We tried this in Plus toolkit and I think there were no major complications.
