Building Cura (dev version) with MinGW-w64 works, but Cura fails on launch.

umagi · February 23, 2016

EDIT:

This post first started out of my initial frustration of not succeeding in building Cura's developer's version in Windows using MingGW-w64 and MSYS2, and trying to get some help. It evolved into a rather long monologue that documents my step-by-step build of the Cura package, the problems I encountered and the sometimes uggly workarounds I used. The final lesson from all this is that building Cura in Windows 7 with MinGW-w64 and MSYS2 works! Hopefully, my post will be of some help to others...

EDIT2:

After installing the freshly built installer package on a Windows 7 Virtual machine... I get an error. So not all is well yet... For the error see my latest entries in this thread below.

EDIT3:

Although the Cura package and installer build to completion, launching the Cura (developer's version) program fails with the error at the end of this thread.

EDIT4:

To have a working Cura build, I just used the daid script (the one that creates the official Cura releases, it seems) from:

https://github.com/daid/Cura

After a few tweaks, the Daid script worked for my installation using the latests MinGW-w64+MSYS2 and the installer package builder NSIS3 except for the build of CuraEngine.exe, which must be compiled from scratch. But I already built it using the cura-build (developer's version) script. Just copying that one and using the rest of the Daid script seems to work. Cura installs and runs correctly as far as I can see.

I still need to figure out why the dev version of Cura crashes after launch though.

Hi

I have been utterly wasting my time trying to build Cura in Windows 7 (64bit) using the instructions from

https://github.com/Ultimaker/cura-build

and also from:

https://github.com/daid/Cura

Both to no avail.

I have installed:

CMake 3.4.3

MinGW-w64 from

https://sourceforge.net/projects/mingw-w64/

msys2 from

https://sourceforge.net/projects/msys2/files/latest/download'

PyQt5-5.5.1: PyQt5-5.5.1-gpl-Py3.4-Qt5.5.1-x64.exe

Python 3.4.4

numpy-1.10.2-win32-superpack-python3.4.exe

I did the following in MSYS2 (and also tried in Git Bash):

git clone git@github.com:Ultimaker/cura-build.gitmkdir buildcd build../env_win64.batcmake -G "MinGW Makefiles" ..mingw32-make

I also tried with env_win32.bat, and also once tried with cmake .. to generate the default generator, which in my case is Visual Studio 14.0 - from VS2015 and tried to build the solution in VS2015. All these trials did not work either...

The build of the Protobuf target succeeds, but then I hit a snag witth the following error:

[  5%] Completed 'Protobuf'[  7%] Built target Protobuf[  7%] Built target Python[  7%] Performing update step for 'Protobuf-python'Current branch master is up to date.[  8%] Performing copy-libproto step for 'Protobuf-python'[  9%] No configure step for 'Protobuf-python'[ 10%] Performing build step for 'Protobuf-python'running buildrunning build_pyrunning build_extbuilding 'google.protobuf.pyext._message' extensionE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_containers.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_containers.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_database.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_database.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_pool.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_pool.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\extension_dict.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\extension_dict.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\map_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\map_container.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\message.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\message.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\repeated_composite_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_composite_container.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\repeated_scalar_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_scalar_container.o -Wno-write-strings -Wno-invalid-offsetofwriting build\temp.win-amd64-3.4\Release\google\protobuf\pyext\_message.defE:\DevTools\MinGW\bin\g++.exe -shared -s build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_containers.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_database.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_pool.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\extension_dict.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\map_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\message.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_composite_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_scalar_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\_message.def -L../src/.libs -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild\amd64 -lprotobuf -lpython34 -lmsvcr100 -o build\lib.win-amd64-3.4\google\protobuf\pyext\_message.pydE:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statuserror: command 'E:\\DevTools\\MinGW\\bin\\g++.exe' failed with exit status 1CMakeFiles\Protobuf-python.dir\build.make:112: recipe for target 'Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build' failedmingw32-make[2]: *** [Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build] Error 1CMakeFiles\Makefile2:292: recipe for target 'CMakeFiles/Protobuf-python.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Protobuf-python.dir/all] Error 2Makefile:148: recipe for target 'all' failedmingw32-make: *** [all] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build

The error is thus:

E:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statuserror: command 'E:\\DevTools\\MinGW\\bin\\g++.exe' failed with exit status 1CMakeFiles\Protobuf-python.dir\build.make:112: recipe for target 'Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build' failedmingw32-make[2]: *** [Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build] Error 1CMakeFiles\Makefile2:292: recipe for target 'CMakeFiles/Protobuf-python.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Protobuf-python.dir/all] Error 2Makefile:148: recipe for target 'all' failedmingw32-make: *** [all] Error 2

Does anyone have an idea about this error or more detailed info about a working build

procedure with detailed configuration info and correct (i.e. compatible) versions for the

various dependencies to use?

Thanks from a very frustrated Cura beginner...

Edited March 1, 2016 by Guest

nallath · February 23, 2016

Why do you want to build it in the first place? The building is to create a distributable.

I'll have a look into our build system in a bit to see what might cause this.

**edit**

I don't ever seem to get the protobuf-python state. Have you updated all repo's to 2.1?

Edited February 23, 2016 by Guest

johank · February 23, 2016

Cura isn't built, it's interpreted

umagi · February 23, 2016

Why do you want to build it in the first place? The building is to create a distributable.

I want to build it to educate myself and to possible mess around with the code later.

I don't ever seem to get the protobuf-python state. Have you updated all repo's to 2.1?

What do you mean by 2.1?

I just use the git cloning procedure:

git clone git@github.com:Ultimaker/cura-build.git

This should give me the master repository and therefore the latest Cura version?

Edited February 23, 2016 by Guest

nallath · February 23, 2016

If you just want to get started you just need to clone:

git clone -b 2.1  git@github.com:Ultimaker/cura.git
git clone -b 2.1 git@github.com:Ultimaker/uranium.git
git clone -b 2.1 git@github.com:Ultimaker/CuraEngine.git
git clone -b 2.1 git@github.com:Ultimaker/libArcus.hit

build libarcus;

cd libArcus
mkdir build
cmake ..
sudo make install

Then build CuraEngine

cd CuraEngine
mkdir build
cmake ..
make

and run in the cura folder (for linux)

PYTHONPATH=.:/usr/local/lib/python3/dist-packages/:../Uranium/ python3 cura_app.py

You also need to ensure that the preferences backend_location is set to the right place.

Python is an interpreted language. There is no need to compile it.

umagi · February 24, 2016

Hi Nallath,

Thanks for your help. I appreciate it.

What do you mean by 2.1?

git clone -b 2.1  git@github.com:Ultimaker/cura.git...

Got it... branch 2.1

But... when making libArcus:

Traceback (most recent call last): File "G:/dev/cura-b2.1/libArcus/cmake/FindSIP.py", line 8, in    import sipconfigImportError: No module named 'sipconfig'CMake Error at cmake/FindSIP.cmake:58 (MESSAGE): Could not find SIPCall Stack (most recent call first): CMakeLists.txt:22 (find_package)

So I tried to dowload and install SIP from here:

https://riverbankcomputing.com/software/sip/download

Then in the sip-4.17 directory, I ran:

python configure.py --platform win32-g++This is SIP 4.17 for Python 3.4.4 on win32.The SIP code generator will be installed in E:\DevTools\Python34.The sip module will be installed in E:\DevTools\Python34\Lib\site-packages.The sip.h header file will be installed in E:\DevTools\Python34\include.The default directory to install .sip files in is E:\DevTools\Python34\sip.Creating siplib\sip.h...Creating siplib\siplib.c...Creating siplib\siplib.sbf...Creating sipconfig.py...Creating top level Makefile...Creating sip code generator Makefile...Creating sip module Makefile...

Then:

 mingw32-makemingw32-make[1]: Entering directory 'G:/dev/cura-b2.1/sip-4.17/sipgen'mingw32-make[1]: Nothing to be done for 'all'.mingw32-make[1]: Leaving directory 'G:/dev/cura-b2.1/sip-4.17/sipgen'mingw32-make[1]: Entering directory 'G:/dev/cura-b2.1/sip-4.17/siplib'gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o siplib.o siplib.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o apiversions.o apiversions.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o descriptors.o descriptors.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o qtlib.o qtlib.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o threads.o threads.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o objmap.o objmap.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o voidptr.o voidptr.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o array.o array.cg++ -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o bool.o bool.cppg++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -shared -Wl,-subsystem,console -Wl,-s -o sip.pyd siplib.o apiversions.o descriptors.o qtlib.o threads.o objmap.o voidptr.o array.o bool.o -LE:\DevTools\Python34\libs -lpython34E:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statusMakefile:36: recipe for target 'sip.pyd' failedmingw32-make[1]: *** [sip.pyd] Error 1mingw32-make[1]: Leaving directory 'G:/dev/cura-b2.1/sip-4.17/siplib'Makefile:3: recipe for target 'all' failedmingw32-make: *** [all] Error 2

So, I basically get the same error as I first reported in this thread.

Python is an interpreted language. There is no need to compile it.

Why does everyone keep telling this? For instance, is the CuraEngine written

in Python? I thought it was written in C++ and therefore needs to be compiled.

Edited February 24, 2016 by Guest

umagi · February 24, 2016

The SIP build succeeds using VS2015's nmake:

G:\dev\cura-b2.1\sip-4.17>nmakeMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation.  All rights reserved.       cd sipgen       "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"Microsoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation.  All rights reserved.       cl -c -nologo -Zm200 -Zc:wchar_t- -FS -Zc:strictStrings -O2 -MD -W0 -DNDEBUG -DUNICODE -DWIN32 -I. -Fo @C:\Users\umagi\AppData\Local\Temp\nmD4EE.tmpmain.ctransform.cgencode.cextracts.cexport.cheap.cparser.clexer.cGenerating Code...       link /NOLOGO /DYNAMICBASE /NXCOMPAT /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:sip.exe.manifest /SUBSYSTEM:CONSOLE /OUT:sip.exe @C:\Users\umagi\AppData\Local\Temp\nmEA82.tmp       mt -nologo -manifest sip.exe.manifest -outputresource:sip.exe;1       cd siplib       "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"Microsoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation.  All rights reserved.       cl -c -nologo -Zm200 -Zc:wchar_t- -FS -Zc:strictStrings -O2 -MD -W0 -DNDEBUG -DUNICODE -DWIN32 -I. -IE:\DevTools\Python34\include -Fo @C:\Users\umagi\AppData\Local\Temp\nmEB3C.tmpsiplib.capiversions.cdescriptors.cqtlib.cthreads.cobjmap.cvoidptr.carray.cGenerating Code...       cl -c -nologo -Zm200 -Zc:wchar_t- -FS -Zc:strictStrings -D_HAS_EXCEPTIONS=0 -O2 -MD -W0 -DNDEBUG -DUNICODE -DWIN32 -I. -IE:\DevTools\Python34\include -Fo @C:\Users\umagi\AppData\Local\Temp\nmEF81.tmpbool.cpp       link /NOLOGO /DYNAMICBASE /NXCOMPAT /DLL /MANIFEST /MANIFESTFILE:sip.pyd.manifest /SUBSYSTEM:CONSOLE /INCREMENTAL:NO/OUT:sip.pyd @C:\Users\umagi\AppData\Local\Temp\nmEFEF.tmp  Creating library sip.lib and object sip.exp       mt -nologo -manifest sip.pyd.manifest -outputresource:sip.pyd;2G:\dev\cura-b2.1\sip-4.17>nmake installMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation.  All rights reserved.       cd sipgen       "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" installMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation.  All rights reserved.       copy /y sip.exe E:\DevTools\Python34\sip.exe       1 file(s) copied.       cd siplib       "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" installMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation.  All rights reserved.       copy /y sip.pyd E:\DevTools\Python34\Lib\site-packages\sip.pyd       1 file(s) copied.       copy /y G:\dev\cura-b2.1\sip-4.17\siplib\sip.h E:\DevTools\Python34\include\sip.h       1 file(s) copied.       copy /y sipconfig.py E:\DevTools\Python34\Lib\site-packages\sipconfig.py       1 file(s) copied.       copy /y G:\dev\cura-b2.1\sip-4.17\sipdistutils.py E:\DevTools\Python34\Lib\site-packages\sipdistutils.py       1 file(s) copied.G:\dev\cura-b2.1\sip-4.17>

With SIP now installed, I resume the Arctus configuration stage, which fails again because it cannot find PROTOBUF:

umagi@HOME-PC MINGW64 /G/dev/cura-b2.1/libArcus/build (2.1)$ cmake -G "MinGW Makefiles" ..-- Could NOT find PROTOBUF (missing:  PROTOBUF_LIBRARY PROTOBUF_INCLUDE_DIR)-- Found SIP version: 4.17CMake Error: The following variables are used in this project, but they are set to NOTFOUND.Please set them or make sure they are set and tested correctly in the CMake files:G:/dev/cura-b2.1/libArcus/PROTOBUF_INCLUDE_DIR  used as include directory in directory G:/dev/cura-b2.1/libArcusPROTOBUF_LIBRARY (ADVANCED)   linked by target "Arcus" in directory G:/dev/cura-b2.1/libArcus-- Configuring incomplete, errors occurred!See also "G:/dev/cura-b2.1/libArcus/build/CMakeFiles/CMakeOutput.log".

Edited February 24, 2016 by Guest

nallath · February 24, 2016

Why does everyone keep telling this? For instance, is the CuraEngine written

in Python? I thought it was written in C++ and therefore needs to be compiled.

The cura engine does need to be built, but that is much much easier to build than building all the distributables for Cura.

As to finding protobuf, did you install protobuf 3 beta 2? You can find it on https://github.com/google/protobuf/releases

umagi · February 24, 2016

As to finding protobuf, did you install protobuf 3 beta 2? You can find it on https://github.com/google/protobuf/releases

I built protobuf and then made cmake point to the .lib file and the include directory:

(Note that I am using NMake now in a VS2015 x64 Native Tools Command Prompt window,

since it seems to work better than with MinGW-w64?)

cmake -G "NMake Makefiles" -DPROTOBUF_INCLUDE_DIR="E:\DevTools\protobuf\include" -DPROTOBUF_LIBRARY="E:\DevTools\protobuf\lib\libprotobuf.lib" ..

After also downloading and compiling SIP, the build of libArcus finally succeeds after changing some incompatible settings in CMakeLists.txt of libArcus:

libprotobuf.lib(structurally_valid.cc.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease'doesn't match value 'MTd_StaticDebug' in sipArcuspart0.cpp.obj

I got a similiar error about static/dynamic is because protobuf was built as a static library, while libArcus by default builds as a dynamic one, and needed to edit libArcus' toplevel CMakeLists.txt file and change the following settings:

option(BUILD_STATIC "Build as a static library" ON)...option(MSVC_STATIC_RUNTIME "Link the MSVC runtime statically" ON)

The actual error above was because protobuf was CMake-configured with DCMAKE_BUILD_TYPE=Release, so I needed to use it for libArcus too.

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DPROTOBUF_INCLUDE_DIR="E:\DevTools\protobuf\include" -DPROTOBUF_LIBRARY="E:\DevTools\protobuf\lib\libprotobuf.lib" ..

So the libArcus part compiles and installs correctly now.

The previous linking error:

 error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit status

was because I installed the 64bit version of python 3.4.4. Replacing it by the 32bit version eliminated that error.

Edited February 24, 2016 by Guest

umagi · February 24, 2016

The next step now... building the Cura Engine...

Unfortunately, this does not seem to be possible using the MSVC compilers because of this error:

g:\dev\cura-b2.1\curaengine\src\utils/gettime.h(: fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directoryNMAKE : fatal error U1077: 'E:\MICROS~1.0\VC\bin\amd64\cl.exe' : return code '0x2'Stop.

Since MSVC does not have a sys/time.h header. I tried to replace the source code by time.h instead, but this gives a bunch of other errors...

I tried to compile it with MinGW instead, but then I get errors relating to the fact that I should probably also build the other dependencies (libArcus and protobuf) using MinGW instead of MSVC?

Edited February 25, 2016 by Guest
typo

umagi · February 24, 2016

OOPS.. this message was posted twice?

No way to delete it myself it seems, so I just left this. Deleting all text does not work...

Edited February 24, 2016 by Guest

nallath · February 24, 2016

We don't build anything with msvc as far as I'm aware.

The building system we use is rather complex and fails quite often, so sorry for that.

umagi · February 25, 2016

I managed to proceed with the build of:

https://github.com/Ultimaker/cura-build

Which automatically checks out branch 2.1

I am at the stage where it starts to build the CuraEngine (I got the all the required dependencies to build, after some tweaks).

For the build, I still used MinGW-w64+MSYS2, but this time with CMake generator "MSYS Makefiles" instead of "MinGW Makefiles". Things seem to go smoother this way, as I don't get the annoying error anymore then:

For MinGW make to work correctly sh.exe must NOT be in your path. Run cmake from a shell that does not have sh.exe in your PATH.

Some say that using MSYS Makefiles make things run slower, but I don't really care for the moment, as long as things get done.

Among the tweaks I had to use was to replace the ./configure part in the Qt build with ./configure.bat to work around the following error:

   The build script does not currently recognize all  platforms supported by Qt.  Rerun this script with a -platform option listed to  set the system/compiler combination you use.

First, I ran the configure.bat script manually, which works fine. Then, to avoid the above error whenever I rerun make, I edited the following script:

%cura-build%/build/CMakeFiles/Qt.dir/build.make

And replaced ./configure by ./configure.bat at the correct location:

Qt-prefix/src/Qt-stamp/Qt-configure: Qt-prefix/src/Qt-stamp/Qt-patch@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir=/G/dev/cura-build/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_7) "Performing configure step for 'Qt'"cd /G/dev/cura-build/build/Qt-prefix/src/Qt && ./configure.bat -release -prefix G:/dev/cura-build/build/inst -archdatadir G:/dev/cura-build/build/inst/lib -datadir G:/dev/cura-build/build/inst/share -opensource -confirm-license -nomake examples -nomake tests -no-cups -skip qtconnectivity -skip qtdoc -skip qtenginio -skip qtlocation -skip qtmultimedia -skip qtquick1 -skip qtscript -skip qtsensors -skip qtwebchannel -skip qtwebengine -skip qtwebkit -skip qtwebsockets -skip qtandroidextras -skip qtactiveqt -skip qttools -skip qtxmlpatterns -skip qt3d -skip qtcanvas3d -skip qtserialport -skip qtwayland -skip qtwebkit-examples -opengl desktopcd /G/dev/cura-build/build/Qt-prefix/src/Qt && /E/DevTools/CMake/bin/cmake.exe -E touch G:/dev/cura-build/build/Qt-prefix/src/Qt-stamp/Qt-configure

Another tweak was to perform the installation part of Sip manually, to work around this strange error:

[ 35%] Performing install step for 'Sip'/usr/bin/sh: -c: line 1: syntax error: unexpected end of fileMakefile:39: recipe for target 'install' failedmingw32-make[4]: *** [install] Error 1Makefile:7: recipe for target 'install' failedmingw32-make[3]: *** [install] Error 2CMakeFiles/Sip.dir/build.make:73: recipe for target 'Sip-prefix/src/Sip-stamp/Sip-install' failedmingw32-make[2]: *** [sip-prefix/src/Sip-stamp/Sip-install] Error 2CMakeFiles/Makefile2:513: recipe for target 'CMakeFiles/Sip.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Sip.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2

The workaround I tried was by first having a dry run (i.e. with the -n Make switch for the install target) of the Makefile:

G:\dev\cura-build\build\Sip-prefix\src\Sip\Makefile

Performing the dry run mingw32-make install -n in the Sip directory above shows which files are to be copied where.

Then, I replaced the build rules for the install target in the above Makefile by direct cp commands:

	cp G:/dev/cura-build/build/Sip-prefix/src/Sip/sipgen/sip.exe G:/dev/cura-build/build/inst/bin/sip.execp G:/dev/cura-build/build/Sip-prefix/src/Sip/siplib/sip.pyd G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sip.pydstrip G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sip.pydcp G:/dev/cura-build/build/Sip-prefix/src/Sip/siplib/sip.h G:/dev/cura-build/build/inst/include/sip.hcp sipconfig.py G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sipconfig.pycp G:/dev/cura-build/build/Sip-prefix/src/Sip/sipdistutils.py G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sipdistutils.py

I know, not very pretty at all, but since I don't know much about build systems like this one, and since it works, I don't really care for now.

Finally, I got to the CuraEngine build, which unfortunately fails too with a rather strange version format error:

Scanning dependencies of target _CuraEngine[  6%] Building CXX object CMakeFiles/_CuraEngine.dir/src/bridge.cpp.obj[  8%] Building CXX object CMakeFiles/_CuraEngine.dir/src/comb.cpp.obj[ 10%] Building CXX object CMakeFiles/_CuraEngine.dir/src/commandSocket.cpp.obj[ 12%] Building CXX object CMakeFiles/_CuraEngine.dir/src/FffGcodeWriter.cpp.obj:0:9: error: too many decimal points in numberG:/dev/cura-build/build/CuraEngine-prefix/src/CuraEngine/src/FffGcodeWriter.cpp:225:59: note: in expansion of macro 'VERSION'    gcode.writeComment("Generated with Cura_SteamEngine " VERSION);                                                          ^G:/dev/cura-build/build/CuraEngine-prefix/src/CuraEngine/src/FffGcodeWriter.cpp: In member function 'void cura::FffGcodeWriter::processStartingCode(cura::SliceDataStorage&'::0:9: error: expected ')' before numeric constantG:/dev/cura-build/build/CuraEngine-prefix/src/CuraEngine/src/FffGcodeWriter.cpp:225:59: note: in expansion of macro 'VERSION'    gcode.writeComment("Generated with Cura_SteamEngine " VERSION);                                                          ^CMakeFiles/_CuraEngine.dir/build.make:146: recipe for target 'CMakeFiles/_CuraEngine.dir/src/FffGcodeWriter.cpp.obj' failedmingw32-make[5]: *** [CMakeFiles/_CuraEngine.dir/src/FffGcodeWriter.cpp.obj] Error 1CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/_CuraEngine.dir/all' failedmingw32-make[4]: *** [CMakeFiles/_CuraEngine.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make[3]: *** [all] Error 2CMakeFiles/CuraEngine.dir/build.make:111: recipe for target 'CuraEngine-prefix/src/CuraEngine-stamp/CuraEngine-build' failedmingw32-make[2]: *** [CuraEngine-prefix/src/CuraEngine-stamp/CuraEngine-build] Error 2CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/CuraEngine.dir/all' failedmingw32-make[1]: *** [CMakeFiles/CuraEngine.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2

The Make dry run shows that VERSION is expanded to 2.0.99-2.1, as set in the top-level cura-build/CMakeLists.txt file, and is passed as

-DVERSION=\"2.0.99-2.1\"

at the command line of g++. So the quotes are escaped correctly.

I'm stuck with this error for the moment, so if anyone has an idea of what's going on, please let me know! Thanks!

Edited February 25, 2016 by Guest

umagi · February 25, 2016

As a temporary workaround, we replaced the VERSION string by a litteral string, i.e.

gcode.writeComment("Generated with Cura_SteamEngine " VERSION);

by:

gcode.writeComment("Generated with Cura_SteamEngine " "2.0.99-2.1");

I needed to do this in the following two files:

G:\dev\cura-build\build\CuraEngine-prefix\src\CuraEngine\src\FffGcodeWriter.cppG:\dev\cura-build\build\CuraEngine-prefix\src\CuraEngine\src\Wireframe2gcode.cpp

After this, CuraEngine proceeds to build to completion!

[ 31%] Linking CXX static library lib_CuraEngine.a[ 95%] Built target _CuraEngine[ 97%] Building CXX object CMakeFiles/CuraEngine.dir/src/main.cpp.obj[100%] Linking CXX executable CuraEngine.exe[100%] Built target CuraEngine[ 89%] Performing install step for 'CuraEngine'[  4%] Built target clipper[ 95%] Built target _CuraEngine[100%] Built target CuraEngineInstall the project...-- Install configuration: "Release"-- Installing: G:/dev/cura-build/build/inst/bin/CuraEngine.exe[ 93%] Completed 'CuraEngine'[100%] Built target CuraEngineumagi@HOME-PC MSYS /g/dev/cura-build/build

Up to the next error in the Cura build...

Edited February 25, 2016 by Guest

umagi · February 25, 2016

EDIT:

The following error is for a MSVC build of Numpy, which is the default on my system.

I leave the info below for reference, but this error does not apply to mingw32 builds of Numpy. Another error happens then, see below.

The build of the Numpy target failed with the following error:

error: Unable to find vcvarsall.batCMakeFiles/Numpy.dir/build.make:113: recipe for target 'Numpy-prefix/src/Numpy-stamp/Numpy-build' failedmingw32-make[2]: *** [Numpy-prefix/src/Numpy-stamp/Numpy-build] Error 1CMakeFiles/Makefile2:218: recipe for target 'CMakeFiles/Numpy.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Numpy.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2

What is happening is that the installer is looking in your environmental variables for the Visual Studio 2010 tools, specifically (other versions of VS will not work)

In Windows 7, Right click on My Computer -> Properties -> Advanced system settings -> Advanced -> Environmental Variables.

In the System Variables, there should be a Variable called VS100COMNTOOLS that points to the Visual Studio 2010 Tools Directory.

A workaround if you have a different version of Visual Studio (e.g. VS2015) is to create a new variable named VS100COMNTOOLS and to set its value to the same as the 2015's VS140COMNTOOLS variable, in my case:

E:\Microsoft Visual Studio 14.0\Common7\Tools\

EDIT: The above error and solution were for an MSVC build of Numpy. Since I wanted a mingw32 build, I had to add the --compiler=mingw32 to the setup.build rule for Numpy in the toplevel cura-build\CMakeLists.txt file:

if(BUILD_NUMPY)   ExternalProject_Add(Numpy       DEPENDS Python       URL http://downloads.sourceforge.net/project/numpy/NumPy/1.9.2/numpy-1.9.2.tar.gz       URL_MD5 a1ed53432dbcd256398898d35bc8e645       CONFIGURE_COMMAND ""       BUILD_COMMAND ${PYTHON_EXECUTABLE} setup.py build --compiler=mingw32       INSTALL_COMMAND ${PYTHON_EXECUTABLE} setup.py install ${python_install}       BUILD_IN_SOURCE 1   endif()

After this modification, don't forget to rerun CMake:

cmake -G "MSYS Makefiles" ..

As as alternative to adding the above build option in CMakeLists.txt you could add the following to file cura-build\build\Numpy-prefix\src\Numpy\numpy\distutils\distutils.cfg (create the file if it doesn't exist):

[build]compiler=mingw32

Since we previously (wrongly) built it with MSVC, we must delete the cura-build/Numpy-prefix folder and relaunch the build for that target:

rm -rf Numpy-prefixmingw32-make Numpy

Then however resulted in the following build error:

build_srcbuilding py_modules sourcesbuilding library "npymath" sourcesBuilding msvcr library: "E:\DevTools\Python34\libs\libmsvcr100.a" (from E:\jre1.8.0_60\bin\msvcr100.dll)objdump.exe: E:\jre1.8.0_60\bin\msvcr100.dll: File format not recognized...prefix\src\Numpy\numpy\distutils\mingw32ccompiler.py", line 278, in generate_def   raise ValueError("Symbol table not found")ValueError: Symbol table not foundCMakeFiles/Numpy.dir/build.make:113: recipe for target 'Numpy-prefix/src/Numpy-stamp/Numpy-build' failedmingw32-make[3]: *** [Numpy-prefix/src/Numpy-stamp/Numpy-build] Error 1CMakeFiles/Makefile2:218: recipe for target 'CMakeFiles/Numpy.dir/all' failedmingw32-make[2]: *** [CMakeFiles/Numpy.dir/all] Error 2CMakeFiles/Makefile2:230: recipe for target 'CMakeFiles/Numpy.dir/rule' failedmingw32-make[1]: *** [CMakeFiles/Numpy.dir/rule] Error 2Makefile:236: recipe for target 'Numpy' failedmingw32-make: *** [Numpy] Error 2

The problem is that the numpy distutils is trying to read the symbol table using "objdump" from msvcr100.dll but it can't recognize the format.

As a workaround, edit the following file where the above check is made:

cura-build\build\Numpy-prefix\src\Numpy\numpy\distutils\mingw32ccompiler.py

Comment out the following lines:

       # Check for custom msvc runtime library on Windows. Build if it doesn't exist.       msvcr_success = build_msvcr_library()       msvcr_dbg_success = build_msvcr_library(debug=True)       if msvcr_success or msvcr_dbg_success:           # add preprocessor statement for using customized msvcr lib           self.define_macro('NPY_MINGW_USE_CUSTOM_MSVCR')

Thus:

        # Check for custom msvc runtime library on Windows. Build if it doesn't exist.       #msvcr_success = build_msvcr_library()       #msvcr_dbg_success = build_msvcr_library(debug=True)       #if msvcr_success or msvcr_dbg_success:       #    # add preprocessor statement for using customized msvcr lib       #    self.define_macro('NPY_MINGW_USE_CUSTOM_MSVCR')

Resuming the build then successfully completed target NumPy:

running install_egg_infoWriting G:\dev\cura-build\build\inst\lib\python3.4\site-packages\numpy-1.9.2-py3.4.egg-inforunning install_clibcopying build\temp.win32-3.4\npymath.lib -> G:\dev\cura-build\build\inst\lib\python3.4\site-packages\numpy\core\lib[ 74%] Completed 'Numpy'[ 78%] Built target Numpy

EDIT:

The PySerial build defaults also to MSVC on my system, so I needed to add the --compiler=mingw32 switch to the setup.py build command in cura-build\CMakeLists.txt, i.e.:

if(BUILD_PYSERIAL)   ExternalProject_Add(PySerial       DEPENDS Python       URL https://pypi.python.org/packages/source/p/pyserial/pyserial-2.7.tar.gz       URL_MD5 794506184df83ef2290de0d18803dd11       CONFIGURE_COMMAND ""       BUILD_COMMAND ${PYTHON_EXECUTABLE} setup.py build --compiler=mingw32       INSTALL_COMMAND ${PYTHON_EXECUTABLE} setup.py install ${python_install}       BUILD_IN_SOURCE 1   )endif()

The build of target PySerial works, but the following SciPy build fails with the following error:

... File "scipy\linalg\setup.py", line 20, in configuration   raise NotFoundError('no lapack/blas resources found')numpy.distutils.system_info.NotFoundError: no lapack/blas resources foundCMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[2]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build

Edited February 25, 2016 by Guest

umagi · February 25, 2016

To build the missing lapack/blas libraries I downloaded the sources from http://www.netlib.org/lapack/lapack.tgz (currently v3.6.0)

EDIT:

v3.6.0 has a bug that leads to undefined references, see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810143

The errors are shown below as per the original posting.

So get Lapack v3.5.0 instead:

http://www.netlib.org/lapack/lapack-3.5.0.tgz

END EDIT

In the unzipped directory, I configured it as follows:

mkdir buildcd buildcmake -G "MSYS Makefiles" ..

Then I build it:

$ mingw32-makeScanning dependencies of target blas[  5%] Linking Fortran static library ../../lib/libblas.a[  5%] Built target blasScanning dependencies of target lapack[ 59%] Built target lapackScanning dependencies of target tmglib...[ 93%] Built target xeigtstd...[100%] Built target xeigtstz

Then, from G:\dev\lapack-3.6.0\build\lib, I copied the following files to my E:\DevTools\Python34\libs directory:

cp G:/dev/lapack-3.6.0/build/lib/libblas.a E:/DevTools/Python34/libs/libblas.acp G:/dev/lapack-3.6.0/build/lib/liblapack.a E:/DevTools/Python34/libs/liblapack.acp G:/dev/lapack-3.6.0/build/lib/libtmglib.a E:/DevTools/Python34/libs/libtmglib.a

Resuming the build then gave:

[ 86%] Performing build step for 'Scipy'...lapack_info: FOUND:   language = f77   libraries = ['lapack']   library_dirs = ['E:\\DevTools\\Python34\\libs']blas_info: FOUND:   language = f77   libraries = ['blas']   library_dirs = ['E:\\DevTools\\Python34\\libs'] FOUND:   language = f77   libraries = ['lapack', 'blas']   library_dirs = ['E:\\DevTools\\Python34\\libs']   define_macros = [('NO_ATLAS_INFO', 1)]

EDIT: The following error occured when running the MSVC build of Scipy, which was the default. I needed to change it to a mingw32 build as shown further below this comment.

And build continues until it hits the following error:

Found executable E:\Microsoft Visual Studio 14.0\VC\BIN\link.exe  Creating library build\temp.win32-3.4\Release\scipy\cluster\_vq.lib and object build\temp.win32-3.4\Release\scipy\cluster\_vq.expgfortran.lib(transfer.o) : error LNK2019: unresolved external symbol _pthread_mutex_lock referenced in function _data_transfer_initgfortran.lib(unix.o) : error LNK2001: unresolved external symbol _pthread_mutex_lockgfortran.lib(unit.o) : error LNK2001: unresolved external symbol _pthread_mutex_lockgfortran.lib(random.o) : error LNK2001: unresolved external symbol _pthread_mutex_lockgfortran.lib(transfer.o) : error LNK2019: unresolved external symbol _pthread_mutex_unlock referenced in function _data_transfer_initgfortran.lib(unix.o) : error LNK2001: unresolved external symbol _pthread_mutex_unlockgfortran.lib(unit.o) : error LNK2001: unresolved external symbol _pthread_mutex_unlockgfortran.lib(random.o) : error LNK2001: unresolved external symbol _pthread_mutex_unlockgfortran.lib(unix.o) : error LNK2019: unresolved external symbol __imp___iob referenced in function __gfortrani_flush_if_preconnectedmingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2001: unresolved external symbol __imp___iobgfortran.lib(unix.o) : error LNK2019: unresolved external symbol _pthread_mutex_trylock referenced in function _flush_all_units_1gfortran.lib(unit.o) : error LNK2001: unresolved external symbol _pthread_mutex_trylockgfortran.lib(unit.o) : error LNK2019: unresolved external symbol _pthread_mutex_init referenced in function _insert_unitgfortran.lib(random.o) : error LNK2001: unresolved external symbol _pthread_mutex_initgfortran.lib(unit.o) : error LNK2019: unresolved external symbol _pthread_mutex_destroy referenced in function _get_external_unitgfortran.lib(write.o) : error LNK2019: unresolved external symbol _signbitq referenced in function _write_floatgfortran.lib(write.o) : error LNK2019: unresolved external symbol _finiteq referenced in function _write_floatgfortran.lib(write.o) : error LNK2019: unresolved external symbol _isnanq referenced in function _write_floatgfortran.lib(backtrace.o) : error LNK2019: unresolved external symbol __Unwind_GetIPInfo referenced in function _trace_functiongfortran.lib(backtrace.o) : error LNK2019: unresolved external symbol __Unwind_Backtrace referenced in function __gfortran_backtracemingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2019: unresolved external symbol __imp__MessageBoxW@16 referenced in function __wassertmingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2019: unresolved external symbol __snwprintf referenced in function __wassertmingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2019: unresolved external symbol _fwprintf referenced in function __wassertmingwex.lib(lib32_libmingwex_a-mingw_pformat.o) : error LNK2019: unresolved external symbol __get_output_format referenced in function ___pformat_emit_efloatmingwex.lib(lib32_libmingwex_a-wcrtomb.o) : error LNK2019: unresolved external symbol __imp____mb_cur_max referenced in function _wcrtombmingwex.lib(lib32_libmingwex_a-mbrtowc.o) : error LNK2001: unresolved external symbol __imp____mb_cur_maxbuild\lib.win32-3.4\scipy\cluster\_vq.pyd : fatal error LNK1120: 16 unresolved externalserror: Command "E:\Microsoft Visual Studio 14.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:E:\DevTools\Python34\libs /LIBPATH:build\temp.win32-3.4\Release /LIBPATH:E:\DevTools\MinGW\lib\gcc\i686-w64-mingw32\5.3.0 /LIBPATH:E:\DevTools\MinGW\i686-w64-mingw32\lib /LIBPATH:E:\DevTools\Python34\libs /LIBPATH:E:\DevTools\Python34\PCbuild /LIBPATH:build\temp.win32-3.4 /LIBPATH:E:\DevTools\Python34\libs /LIBPATH:E:\DevTools\Python34\PCbuild /LIBPATH:build\temp.win32-3.4 lapack.lib blas.lib gfortran.lib gcc.lib mingw32.lib mingwex.lib /EXPORTyInit__vq build\temp.win32-3.4\Release\scipy\cluster\_vq.obj /OUT:build\lib.win32-3.4\scipy\cluster\_vq.pyd /IMPLIB:build\temp.win32-3.4\Release\scipy\cluster\_vq.lib /MANIFESTFILE:build\temp.win32-3.4\Release\scipy\cluster\_vq.pyd.manifest" failed with exit status 1120CMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[2]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2

EDIT:

The above clearly uses the VS2015 linker because the default Scipy build uses the default compiler on my system, VS2015.

To change the Scipy build to mingw32 we need to change the toplevel CMakeLists.txt file again and add the --compiler=mingw32 option to the setup.py build command:

if(BUILD_SCIPY)   ExternalProject_Add(Scipy       DEPENDS Python Numpy       URL http://downloads.sourceforge.net/project/scipy/scipy/0.16.1/scipy-0.16.1.tar.gz       CONFIGURE_COMMAND ""       BUILD_COMMAND ${PYTHON_EXECUTABLE} setup.py build --compiler=mingw32       INSTALL_COMMAND ${PYTHON_EXECUTABLE} setup.py install ${python_install}       BUILD_IN_SOURCE 1   endif()

Again, don't forget to rerun CMake after this!

cmake -G "MSYS Makefiles" ..

After deleting the cura-build\build\Scipy-prefix directory (to delete the previous MSVC build results), I restarted the build for mingw32:

 mingw32-make Scipy

Of course, I did not get the same error as above, but another one:

ompiling Fortran sourcesFortran f77 compiler: E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -ffixed-form -fno-second-underscore -O3 -funroll-loopsFortran f90 compiler: E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -fno-second-underscore -O3 -funroll-loopsFortran fix compiler: E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -ffixed-form -fno-second-underscore -Wall -g -fno-second-underscore -O3 -funroll-loop               scompile options: '-DNO_ATLAS_INFO=1 -Ibuild\src.win32-3.4 -IG:\dev\cura-build\build\inst\lib\python3.4\site-packages\numpy\core\include -IE:\DevTools\P               ython34\include -IE:\DevTools\Python34\include -c'gfortran.exe:f77: G:\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src\wrap_dummy_g77_abi.fgfortran.exe:f77: G:\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src\wrap_dummy_accelerate.fgfortran.exe:f77: build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack-f2pywrappers.fE:\DevTools\MinGW\bin\gfortran.exe -Wall -g -Wall -g -shared build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack               module.o build\temp.win32-3.4\Release\build\src.win32-3.4\fortranobject.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefix\src\Scipy\scip               y\_build_utils\src\wrap_dummy_g77_abi.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src\wrap_dummy_acce               lerate.o build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack-f2pywrappers.o -LE:\DevTools\Python34\libs -LE:\Dev               Tools\MinGW\lib\gcc\i686-w64-mingw32\5.3.0 -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild -Lbuild\temp.win32-3.4 -llapack -lblas -lpython34                -lgfortran -o build\lib.win32-3.4\scipy\linalg\_flapack.pydbuild\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x7fbc): undefined reference                to `sgegv_'build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x8074): undefined reference                to `dgegv_'build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x812c): undefined reference                to `cgegv_'build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x81e4): undefined reference                to `zgegv_'collect2.exe: error: ld returned 1 exit statuserror: Command "E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -Wall -g -shared build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy               \linalg\_flapackmodule.o build\temp.win32-3.4\Release\build\src.win32-3.4\fortranobject.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefi               x\src\Scipy\scipy\_build_utils\src\wrap_dummy_g77_abi.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src               \wrap_dummy_accelerate.o build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack-f2pywrappers.o -LE:\DevTools\Python               34\libs -LE:\DevTools\MinGW\lib\gcc\i686-w64-mingw32\5.3.0 -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild -Lbuild\temp.win32-3.4 -llapack -               lblas -lpython34 -lgfortran -o build\lib.win32-3.4\scipy\linalg\_flapack.pyd" failed with exit status 1CMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[3]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[2]: *** [CMakeFiles/Scipy.dir/all] Error 2CMakeFiles/Makefile2:488: recipe for target 'CMakeFiles/Scipy.dir/rule' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/rule] Error 2Makefile:327: recipe for target 'Scipy' failedmingw32-make: *** [scipy] Error 2

These errors are due to a bug in Lapack v3.6.0 as mentioned above, and do not occur when using v3.5.0. Build v3.5.0 and copy the generated library files to the Python Libs directory as described above.

Edited February 25, 2016 by Guest

umagi · February 25, 2016

Resuming the SciPy build first gave another error:

error: [Errno 24] Too many open files

I just restarted MSYS2 and resumed the build (since ulimit was already set to unlimited, there is was no way to increase the memory for commands that way?)

Resuming the build gave a final error for the Scipy build:

running build_clibBuilding msvcr library: "E:\DevTools\Python34\libs\libmsvcr100.a" (from E:\jre1.8.0_60\bin\msvcr100.dll)objdump.exe: E:\jre1.8.0_60\bin\msvcr100.dll: File format not recognizedE:\DevTools\Python34\lib\distutils\dist.py:260: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg)E:\DevTools\Python34\lib\distutils\dist.py:260: UserWarning: Unknown distribution option: 'install_requires' warnings.warn(msg)E:\DevTools\Python34\lib\distutils\dist.py:260: UserWarning: Unknown distribution option: 'setup_requires' warnings.warn(msg)E:\DevTools\Python34\lib\site-packages\numpy\distutils\system_info.py:1505: UserWarning:   Atlas (http://math-atlas.sourceforge.net/'>http://math-atlas.sourceforge.net/) libraries not found.   Directories to search for the libraries can be specified in the   numpy/distutils/site.cfg file (section [atlas]) or by setting   the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__)Running from scipy source directory.E:\DevTools\Python34\lib\site-packages\numpy\distutils\system_info.py:594: UserWarning: Specified path E:\DevTools\Python34\include\include is invalid. warnings.warn('Specified path %s is invalid.' % d)E:\DevTools\Python34\lib\site-packages\numpy\distutils\system_info.py:1603: UserWarning:   Atlas (http://math-atlas.sourceforge.net/) libraries not found.   Directories to search for the libraries can be specified in the   numpy/distutils/site.cfg file (section [atlas]) or by setting   the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__)Traceback (most recent call last): File "setup.py", line 253, in    setup_package() File "setup.py", line 250, in setup_package   setup(**metadata) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\core.py", line 169, in setup   return old_setup(**new_attr) File "E:\DevTools\Python34\lib\distutils\core.py", line 148, in setup   dist.run_commands() File "E:\DevTools\Python34\lib\distutils\dist.py", line 955, in run_commands   self.run_command(cmd) File "E:\DevTools\Python34\lib\distutils\dist.py", line 974, in run_command   cmd_obj.run() File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\command\build.py", line 39, in run   old_build.run(self) File "E:\DevTools\Python34\lib\distutils\command\build.py", line 126, in run   self.run_command(cmd_name) File "E:\DevTools\Python34\lib\distutils\cmd.py", line 313, in run_command   self.distribution.run_command(command) File "E:\DevTools\Python34\lib\distutils\dist.py", line 974, in run_command   cmd_obj.run() File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\command\build_clib.py", line 72, in run   force=self.force) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\ccompiler.py", line 562, in new_compiler   compiler = klass(None, dry_run, force) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 94, in __init__   msvcr_success = build_msvcr_library() File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 361, in build_msvcr_library   generate_def(dll_file, def_file) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 278, in generate_def   raise ValueError("Symbol table not found")ValueError: Symbol table not foundCMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[3]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[2]: *** [CMakeFiles/Scipy.dir/all] Error 2CMakeFiles/Makefile2:488: recipe for target 'CMakeFiles/Scipy.dir/rule' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/rule] Error 2Makefile:327: recipe for target 'Scipy' failedmingw32-make: *** [scipy] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build

This is exactly the same error as I got during the build of Numpy, but this time, the file that throws the error is:

E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py

I just repeated the workaround described above for that error, and resumed the build.

Finally, the Scipy build completed:

creating G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy\sparse\linalg\eigen\lobpcg\testscopying scipy\sparse\linalg\eigen\lobpcg\tests\test_lobpcg.py -> G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy\sparse\linalg\eigen\lobpcg\tests\running install_egg_infoWriting G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy-0.16.1-py3.4.egg-inforunning install_clib[ 71%] Completed 'Scipy'[100%] Built target Scipy

umagi · February 26, 2016

The build of target cura-binary-data goes smoothly, mainly because it just appears to download and copy the firmware binaries, it does not build them here (who does that?):

Scanning dependencies of target cura-binary-data[ 93%] Creating directories for 'cura-binary-data'[ 94%] Performing download step (git clone) for 'cura-binary-data'Cloning into 'cura-binary-data'...Branch 2.1 set up to track remote branch 2.1 from origin.Switched to a new branch '2.1'[ 95%] No patch step for 'cura-binary-data'[ 96%] Performing update step for 'cura-binary-data'Current branch 2.1 is up to date.[ 97%] Performing configure step for 'cura-binary-data'-- The C compiler identification is GNU 5.3.0...-- Configuring done-- Generating done-- Build files have been written to: G:/dev/cura-build/build/cura-binary-data-prefix/src/cura-binary-data-build[ 98%] Performing build step for 'cura-binary-data'[ 99%] Performing install step for 'cura-binary-data'Install the project...-- Install configuration: ""-- Up-to-date: G:/dev/cura-build/build/inst/share/cura-- Up-to-date: G:/dev/cura-build/build/inst/share/cura/resources-- Installing: G:/dev/cura-build/build/inst/share/cura/resources/firmware-- Installing: G:/dev/cura-build/build/inst/share/cura/resources/firmware/Attribution.txt-- Installing: G:/dev/cura-build/build/inst/share/cura/resources/firmware/MarlinUltimaker-115200-dual.hex...-- Installing: G:/dev/cura-build/build/inst/./arduino/dpinst64.exe[100%] Completed 'cura-binary-data'[100%] Built target cura-binary-data

Then, finally, the build of the build_exe target starts ... and stops with the following error:

Scanning dependencies of target build_exeRunning py2exeTraceback (most recent call last): File "setup_win32.py", line 5, in    import py2exeImportError: No module named 'py2exe'CMakeFiles/build_exe.dir/build.make:57: recipe for target 'build_exe' failedmingw32-make[2]: *** [build_exe] Error 1CMakeFiles/Makefile2:588: recipe for target 'CMakeFiles/build_exe.dir/all' failedmingw32-make[1]: *** [CMakeFiles/build_exe.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2

I had to install the py2exe package.

Make sure to install the latest version (0.9.2.2), otherwise you may get the following error during the build of the build_exe target:

KeyError: 'six.moves'

The Windows installer (choose win32 version, since we had to install the 32bit version of Python to build Cura) can be dowloaded here:

https://pypi.python.org/packages/any/p/py2exe/py2exe-0.9.2.2.win32.exe#md5=f1684d39de2ed8287a0a36eb241f81e5

The source code can be downloaded here:

https://pypi.python.org/packages/source/p/py2exe/py2exe-0.9.2.2.zip#md5=f7d7e3980a606b4ded4d98016759d557

Install it as usual using:

python setup.py buildpython setup.py install

Or better, install it using pip:

pip install py2exe

Finally, after installing the correct version of py2exe and resuming the build, the target builds to completion! Finally!

Running py2exeRemoving previous distribution packagerunning py2exerunning build_scripts 27 missing Modules ------------------? FCNTL imported from serial.serialposix? Image imported from scipy.misc.pilutil? ImageFilter imported from scipy.misc.pilutil? PIL imported from scipy.misc.pilutil? System imported from serial.serialcli? TERMIOS imported from serial.serialposix? backports imported from setuptools.ssl_support? google.protobuf._use_fast_cpp_protos imported from google.protobuf.internal.api_implementation? google.protobuf.internal._api_implementation imported from google.protobuf.internal.api_implementation? matplotlib imported from scipy.spatial._plotutils? netbios imported from uuid? packaging imported from pkg_resources? readline imported from cmd, code, pdb? scikits imported from scipy.sparse.linalg.dsolve.linsolve? scipy.arange imported from scipy.sparse.linalg.isolve.minres? scipy.ones imported from scipy.sparse.linalg.isolve.minres? sets imported from numpy.distutils.command.build_ext, numpy.distutils.fcompiler, numpy.distutils.misc_util? setuptools_svn imported from setuptools.command.egg_info? urllib.pathname2url imported from setuptools.compat? urllib.splittag imported from setuptools.compat? urllib.url2pathname imported from setuptools.compat? win32api imported from distutils.msvccompiler? win32com imported from setuptools.sandbox? win32con imported from distutils.msvccompiler? win32pdh imported from numpy.testing.utils? win32wnet imported from uuid? wincertstore imported from setuptools.ssl_support 1 submodules that appear to be missing, but could also be global names in the parent package ---------------------------------------------------------------------------------------------? numpy.conj imported from scipy.linalg.decompBuilding 'dist\cura_app.exe'.Building shared code archive 'dist\library.zip'.Copy c:\windows\system32\python34.dll to dist...Copy G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy\spatial\ckdtree.pyd to dist\scipy.spatial.ckdtree.pydCopy E:\DevTools\Python34\DLLs\pyexpat.pyd to dist\pyexpat.pydCopy DLL E:\DevTools\MinGW\bin\libgcc_s_dw2-1.dll to dist\...Copy DLL E:\DevTools\MinGW\bin\libquadmath-0.dll to dist\Copying Cura plugins.Copying resources.Coping Uranium QML.Copying Qt5 pluginsCopying QtQuick pluginsCopying Qt5 svg libraryCopy CuraEngine[100%] Built target build_exe

I'm not sure what the above report of missing modules (27 + possibly 1) implies, but the build finishes. Let's wait until the next step (packaging) before claiming victory...

umagi · February 26, 2016

Finally, I called "mingw32-make package" to build the Cura installer.

mingw32-make package

As expected, we get the following error, since we did not install NSIS:

Run CPack packaging tool...CPack Error: Cannot find NSIS compiler makensis: likely it is not installed, or not in your PATHCPack Error: Could not read NSIS registry value. This is usually caused by NSIS not being installed. Please install NSIS from http://nsis.sourceforge.netCPack Error: Cannot initialize the generator NSISMakefile:117: recipe for target 'package' failedmingw32-make: *** [package] Error 1

NSIS can be downloaded from: http://nsis.sourceforge.net/Main_Page

As suggested in the README.md from the cura-build page, I downloaded version 3:

The windows installer and sources can be downloaded from:

http://prdownloads.sourceforge.net/nsis/nsis-3.0b3-setup.exe?download

http://prdownloads.sourceforge.net/nsis/nsis-3.0b3-src.tar.bz2?download

Resuming the build of the installer after installing NSIS 3, we get the following error:

Run CPack packaging tool...CPack: Create package using NSISCPack: Install projectsCPack: - Run preinstall target for: cura-buildCPack: - Install project: cura-buildCPack: -   Install component: arduinoCMake Error at G:/dev/cura-build/build/cmake_install.cmake:39 (file): file INSTALL cannot find "G:/dev/cura-build/arduino".CPack Error: Error when generating package: CuraMakefile:117: recipe for target 'package' failedmingw32-make: *** [package] Error 1

So it tries to find a package called arduino, which I don't seem to have (although Arduino 1.6.7 is installed on my system).

Edited February 26, 2016 by Guest

umagi · February 26, 2016

To solve the above error (not sure it is correct), I downloaded the Arduino master repository as zip file (about 82.3MByte, and about 326MByte unzipped. I did not clone the master, which is about 1.5GByte!)

https://github.com/arduino/Arduino/archive/master.zip

Then copy the unzipped Arduino-master folder (and rename it to arduino) to:

cura-build/arduino

Resuming the package build step, we get the following error after this:

Run CPack packaging tool...CPack: Create package using NSISCPack: Install projectsCPack: - Run preinstall target for: cura-buildCPack: - Install project: cura-buildCPack: -   Install component: arduinoCPack: -   Install component: curaCPack: -   Install component: vcredistCMake Error at G:/dev/cura-build/build/cmake_install.cmake:35 (file): file INSTALL cannot find "G:/dev/cura-build/vcredist_x86.exe".CPack Error: Error when generating package: CuraMakefile:117: recipe for target 'package' failedmingw32-make: *** [package] Error 1

As mentioned in the cura-build\CMakeLists.txt file, we need to get the distributable from:

http://www.microsoft.com/en-us/download/details.aspx?id=26999

We downloaded the vcredist_x86.exe (because we have a 32bit build) and copied it to the cura-build directory.

After this step: Success!!!

Run CPack packaging tool...CPack: Create package using NSISCPack: Install projectsCPack: - Run preinstall target for: cura-buildCPack: - Install project: cura-buildCPack: -   Install component: arduinoCPack: -   Install component: curaCPack: -   Install component: vcredistCPack: Create packageCPack: - package: G:/dev/cura-build/build/Cura-2.0.99-2.1-win32.exe generated.

Of course, I still need to check if this thing actually installs and runs...

Edited February 26, 2016 by Guest

umagi · February 26, 2016

I installed the newly built Cura package on a Windows 7 virtual machine (64bit, as my build host) but got the following error upon launching Cura (the installer works fine):

Errors in 'Cura.exe'See logfile 'C:\Program Files (x86)\Cura 2.0\Cura.log' for details.

That logfile shows:

Error in sys.excepthook:Traceback (most recent call last): File "", line 2237, in _find_and_load File "", line 2226, in _find_and_load_unlocked File "", line 1191, in _load_unlocked File "", line 1161, in _load_backward_compatible File "G:\dev\cura-build\build\inst\lib\python3.4\site-packages\cura\CrashHandler.py", line 6, in  File "", line 10, in  File "", line 8, in __loadImportError: (DLL load failed: The specified module could not be found.) 'C:\\Program Files (x86)\\Cura 2.0\\PyQt5.QtCore.pyd'Original exception was:Traceback (most recent call last): File "cura_app.py", line 20, in  File "G:\dev\cura-build\build\inst\lib\python3.4\site-packages\cura\CuraApplication.py", line 6, in  File "G:\dev\cura-build\build\inst\lib\python3.4\site-packages\UM\Qt\QtApplication.py", line 9, in  File "", line 10, in  File "", line 8, in __loadImportError: (DLL load failed: The specified module could not be found.) 'C:\\Program Files (x86)\\Cura 2.0\\PyQt5.QtCore.pyd'

umagi · February 27, 2016

I started the build from scratch, using my newly gained experience from the above steps and deleted the cura-build/build directory.

Note: It seems building under MSYS2 seems a little bit unstable? I got errors such as Too many open files, and another error relating to some truncated object file?

In any case, after the new build, the Cura 2.0 exe starts:

Edited February 27, 2016 by Guest

nallath · February 29, 2016

I don't really know what caused the crash you have now.

I'd suggest running the python stuff from source and copy the artifacts that you do need (eg; CuraEngine)

umagi · March 1, 2016

Hi Nallath.

EDIT: Sorry, you already mentioned to run the Python stuff from source... I didn't initially get what you meant by that...

I'd suggest running the python stuff from source and copy the artifacts that you do need (eg; CuraEngine)

How do I run the Cura python part from source in the cura-build build?

Is it done by launching cura_app.py from the cura-build\build\Cura-prefix\src\Cura directory?

Many thanks!

Edited March 1, 2016 by Guest

nallath · March 1, 2016

Yep.

So in my case (I checked out both Cura and Uranium in my Development folder) I use

 PYTHONPATH=.:/usr/local/lib/python3/dist-packages/:../Uranium/ python3 cura_app.py

in order to start Cura. I run this from the Cura folder.

Building Cura (dev version) with MinGW-w64 works, but Cura fails on launch.

Recommended Posts

umagi 8

Link to post

Share on other sites

nallath 1,118

Link to post

Share on other sites

johank 7

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

nallath 1,118

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

nallath 1,118

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

nallath 1,118

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

nallath 1,118

Link to post

Share on other sites

umagi 8

Link to post

Share on other sites

nallath 1,118

Link to post

Share on other sites

Create an account or sign in to comment

Create an account

Sign in