Ultimaker
Issues encountered getting cura-build-environment for Cura 4.9 working on Windows 1904
Issue 1:
Occurs when trying to build cura-build-environment:
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.17/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/Thomas/Documents/Cura/cura-build-environment-4.9/b2/CMakeFiles/CMakeTmp
Run Build Command(s):nmake /nologo cmTC_198bc\fast && "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" -f CMakeFiles\cmTC_198bc.dir\build.make /nologo -L CMakeFiles\cmTC_198bc.dir\build
Building C object CMakeFiles/cmTC_198bc.dir/testCCompiler.c.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe @C:\Users\Thomas\AppData\Local\Temp\nmC10C.tmp
cl : Command line warning D9002 : ignoring unknown option '-m64'
testCCompiler.c
Linking C executable cmTC_198bc.exe
"C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_198bc.dir --rc=rc --mt=CMAKE_MT-NOTFOUND --manifests -- C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\cmTC_198bc.dir\objects1.rsp @C:\Users\Thomas\AppData\Local\Temp\nmC284.tmp
RC Pass 1: command "rc /fo CMakeFiles\cmTC_198bc.dir/manifest.res CMakeFiles\cmTC_198bc.dir/manifest.rc" failed (exit code 0) with the following output:
The system cannot find the file specifiedNMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:4 (project)
Fix:
Change line one in env_win64.bat to call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1
Issue 2:
Happens when trying to start cura(python Cura-4.9\cura_app.py --external-backend ) using compiled cura-build-environment (to supply the dependencies):
Traceback (most recent call last):
File "Cura-4.9\cura_app.py", line 32, in <module>
from cura.CrashHandler import CrashHandler
File "C:\Users\Thomas\Documents\Cura\Cura-4.9\cura\CrashHandler.py", line 27, in <module>
from UM.Application import Application
File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Application.py", line 9, in <module>
from UM.Controller import Controller
File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Controller.py", line 3, in <module>
from UM.Scene.Iterator.DepthFirstIterator import DepthFirstIterator
File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Scene\Iterator\DepthFirstIterator.py", line 3, in <module>
from UM.Scene.SceneNode import SceneNode
File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Scene\SceneNode.py", line 14, in <module>
from UM.Mesh.MeshBuilder import MeshBuilder
File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Mesh\MeshBuilder.py", line 4, in <module>
from UM.Mesh.MeshData import MeshData
File "C:\Users\Thomas\Documents\Cura\cura-libs\Uranium\UM\Mesh\MeshData.py", line 16, in <module>
import scipy.spatial
File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\spatial\__init__.py", line 102, in <module>
from ._geometric_slerp import geometric_slerp
File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\spatial\_geometric_slerp.py", line 8, in <module>
from scipy.spatial.distance import euclidean
File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\spatial\distance.py", line 122, in <module>
from ..special import rel_entr
File "C:\Users\Thomas\Documents\Cura\cura-build-environment\lib\site-packages\scipy\special\__init__.py", line 633, in <module>
from . import _ufuncs
ImportError: DLL load failed while importing _ufuncs: The specified module could not be found.
Fix:
Copy DLLs from cura-build-environment\lib\site-packages\numpy\core to cura-build-environment\lib\site-packages\numpy\DLLs
The files seems to be moved away from there in projects/python_packages.cmake line 66ff.
Issue 3:
If python 3.8 is already installed on the System, some of the Savitar module files are copied into the native python installation(for example in appData), and not into the target one(cbe_install_dir).
Fix:
Deinstalling python 3.8 from the system.
Result:
After these changes, the build environment seems to be working for me.
It's very kind to see how proactive you are with coming up with solutions to these problems and sharing them.
Change line one in env_win64.bat to
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1
As I understand from documentation, this causes it to use the Windows 8.1 SDK, but currently we can't do that since our build server is still Windows 7. We're working on a migration, but it's apparently a lot of work. Weird though that apparently using the most recent SDK would break the build process? Perhaps there is one such SDK version number that is available for Windows 7 as well. Perhaps @evtrados would like to know about this, as he's been on this issue recently.
Copy DLLs from cura-build-environment\lib\site-packages\numpy\core to cura-build-environment\lib\site-packages\numpy\DLLs The files seems to be moved away from there in projects/python_packages.cmake line 66ff.
Seems like we've more or less encountered the reverse. The DLLs need to be moved to the /core directory because that's where cx_Freeze looks for them. See also https://github.com/marcelotduarte/cx_Freeze/issues/653 .
Issue 3 is indeed a known issue. It also happens for libArcus. It's not a problem in cura-build-environment but rather in those repositories itself. It's very annoying on Linux because the build then suddenly needs administrator access to install things into the Python dist-packages folder.
