Forum archiveIssue archiveInstallation and Building

Archived discussion

Building OCCT using MinGW

Installation and BuildingWed, 03/09/2016 - 13:529 replies

Browse this forum
QuestionAuthor

Open CASCADE Technology 7.0.0.rc can be built using MinGW-w64 on Windows platform.

MinGW is a minimalistic development environment for developing native Windows applications based on GCC. Project MinGW-w64 is its fork aimed to support 64-bit target and new APIs.

GCC (GNU Compiler Collection) remains a main compiler on Linux platform, but is a second-class citizen on platforms like Windows (with dominating msvc - a C/C++ compiler from Microsoft Visual Studio) or OS X (where Apple has pushed developers towards clang).

break

GCC provides a strong C/C++ compiler supporting C/C++ features from the most recent standards (including C99 standard abandoned by Microsoft in msvc) and efficient optimizations. Although quite rarely used on Windows, GCC might be still reasonable choice for developers within particular scenarios. OCCT relies on msvc as a main compiler on Windows platform. However, since OCCT 7.0.0 (see related issue on bugtracker #0027197) it is now also possible to use GCC (MinGW-w64) for building. It should be noted, however, that MinGW builds are not yet officially maintained by Open CASCADE team (no regression testing etc.). It is also important to note that GCC uses different mechanisms for implementing C++ features, which are completely incompatible with msvc. Thus DLLs built using MinGW can be used only within application using MinGW as well. Moreover, GCC uses different format for debugging symbols, which is not supported by Visual Studio compiler - GDB should be used instead.

Building OCCT using MinGW

Two ways can be considered to build OCCT using MinGW - CMake and Code::Blocks project files generator (tcl-based genproj.bat tool packaged with OCCT). CMake supports Code::Blocks project files as well ("CodeBlocks - MinGW Makefiles"), but in contrast to genproj.bat, CMake generates these project files without keeping OCCT projects structure and relies on Makefiles rather than built-in Code::Blocks compiler plugins. Cross-compiling should be also possible (one of the benefits of MinGW), but is not considered/tested within this article. As a prerequisite for building OCCT, its dependencies should be built. It is recommended to use Msys2 project for this task, which dramatically simplifies building libraries like Tcl/Tk by providing shell and usual Unix tools. The building of OCCT itself relies on MinGW only and does not depend on msys2.

Configuring MinGW within CMake

For building using CMake, just follow the general guideline. At the very first step you should specify one of the generator option supporting MinGW - e.g. "MinWG Makefiles". CMake will automatically find MinGW tools from current %PATH%, so if you have not configured it system-wide, you can launch cmake-gui within mingwvars.bat environment (the script provided within MinGW installation path). After generation, just go to the folder with generated Makefiles and use mingw32-make.exe as usual make tool in Unix environment. Archived image: CMake configured for MinGW

Generating Code::Blocks projects using genproj.bat

For using genproj.bat (as alternative to CMake), follow the general guideline for using genproj (configure dependencies using genconf.bat).
Archived image: genconf for MinGW
At the end of the script genproj.bat the -target=%VCVER% should be replaced by -target=cbp to generate Code::Blocks project files:

%TCL_EXEC% %~dp0adm/start.tcl genproj -path=. -target=cbp

After that, the Code::Blocks workspace should be started by codeblocks.bat script. Mingw should be configured within Code::Blocks itself. Activate project DRAWEXE within workspace to launch Draw Harness directly from Code::Blocks. The project files generated in this way will be portable - you will need only to call genconf.bat (or to edit custom.bat to use relative paths) when moving OCCT to another computer.

Conclusion

OCCT can be built on one more platform - using MinGW for Windows target. If you are using MinGW - please share your experience. Author

Discussion

9 archived replies

Posts are displayed in their archived order.

01Commenter-1

Building without additional libraries (like FreeImage and Gl2Ps) works great. Still it seems to me as if the MinGw build is not perfect yet, when additional libraries are used.

I have created the issue 0027397, which proposes to offer precompiled additional libraries in the download center.

But in the meantime, could you give more hints on how to build OCCT with MinGw when additional libraries are used?

Issues:
- It seems as if the CMake configuration is buggy. Static libraries created with MinGw look like that: libLibrary.a. If the "3rdparty" folder contains FreeImage and Gl2Ps like that, CMake complains that it couldn't find them. It seems as if you have adjusted that already for FreeType. Could you do it for all optional libraries?
- If I duplicate the libraries and give one file the name as chosen by MSVC, CMake accepts it and I can generate a Makefile. But during compilation, I receive the error message inserted below.

Error message:

[ 46%] Linking CXX shared library ../../win64/gcc/bin/libTKOpenGl.dll
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Text.cxx.obj):OpenGl_Text.cxx:(.text+0x39b1): undefined reference to `gl2psTextOpt'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Workspace.cxx.obj):OpenGl_Workspace.cxx:(.text+0x2104): undefined reference to `gl2psPointSize'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Workspace.cxx.obj):OpenGl_Workspace.cxx:(.text+0x2ae6): undefined reference to `gl2psPointSize'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Workspace.cxx.obj):OpenGl_Workspace.cxx:(.text+0x2dd3): undefined reference to `gl2psPointSize'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Workspace.cxx.obj):OpenGl_Workspace.cxx:(.text+0x32d3): undefined reference to `gl2psPointSize'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_View.cxx.obj):OpenGl_View.cxx:(.text+0x4ea): undefined reference to `gl2psEndPage'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_View.cxx.obj):OpenGl_View.cxx:(.text+0x577): undefined reference to `gl2psBeginPage'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_View.cxx.obj):OpenGl_View.cxx:(.text+0x71a): undefined reference to `gl2psEndPage'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_View.cxx.obj):OpenGl_View.cxx:(.text+0x78c): undefined reference to `gl2psBeginPage'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Context.cxx.obj):OpenGl_Context.cxx:(.text+0xbc25): undefined reference to `gl2psDisable'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Context.cxx.obj):OpenGl_Context.cxx:(.text+0xbc36): undefined reference to `gl2psEnable'
CMakeFiles/TKOpenGl.dir/objects.a(OpenGl_Context.cxx.obj):OpenGl_Context.cxx:(.text+0x92f9): undefined reference to `gl2psLineWidth'
collect2.exe: error: ld returned 1 exit status
src/TKOpenGl/CMakeFiles/TKOpenGl.dir/build.make:1594: recipe for target `win64/gcc/bin/libTKOpenGl.dll' failed
make[2]: *** [win64/gcc/bin/libTKOpenGl.dll] Error 1
CMakeFiles/Makefile2:1326: recipe for target `src/TKOpenGl/CMakeFiles/TKOpenGl.dir/all' failed
make[1]: *** [src/TKOpenGl/CMakeFiles/TKOpenGl.dir/all] Error 2
Makefile:127: recipe for target `all' failed
make: *** [all] Error 2

Have you compiled OCCT with MinGw with optional libraries? Can you post here, how you did that?

Thank you very much!

02Author

We have played a bit with MinGW to check what kind of problems it have with OCCT. But obviously, we don't have much interest working on it since there are no much reasons why users would use this configuration at all.

So if you are interested improving the current state - your contributions are welcome!

Have you compiled OCCT with MinGw with optional libraries? Can you post here, how you did that?

We have not tried this, so some modifications in CMake scripts might be indeed required.

P.S.: if you put bug number with leading # on this forum it will be automatically converted into URL to the mantis issue (e.g. #0027397).

03Commenter-2

because i am working on different projects in parallel, i only had times to apply your advices this morning. But i downloaded the PR3 version before... and the problem deasepeared !

So, i suspect my problem was taken into account before delivering the PR3 version because i didn't do anything more before.

But thanks for your help!

04Commenter-1

Okay, I will have a look at it. Is this the right place to communicate?

Would you help me with hints where to start? Am I right, that I probably have to adjust the adm\cmake\*.cmake files to fix the build with the additional libraries?

There must be something different with FreeType, since FreeType works, but I did not find the difference. The file freetype.cmake does not use the macro THIRDPARTY_PRODUCT. Is the reason for that that it takes care of two libraries at once (also FreeType Plus)? Have you done the modifications for FreeType to run with MinGw builds? Where have you done them? Thanks!

05Commenter-1

Author, maybe I have solved the problem. I will contribute my changes as soon as I am sure.

As for why someone would want to use MinGw - I will post some of my experiences to the forum as soon as everything works.

06Author

Author, maybe I have solved the problem. I will contribute my changes as soon as I am sure.

Great! Of course we can discuss details on this forum, but as soon as context of bug/feature become clear - it might be more convenient to use bugtracker (since bugtracker and OCCT git have direct relationship).

As for why someone would want to use MinGw - I will post some of my experiences to the forum as soon as everything works.

It would be very interesting! E.g., I'm understand why one would build FFmpeg using MinGW (embedding assembler optimizations), but what is the benefit in case of OCCT - it is not clear for me. And I don't think that cross-compiling might be a reason.

07Author

I will post some of my experiences to the forum as soon as everything works.

Thank you for posting interesting comparison!
http://www.opencascade.com/content/mingw-w64-vs-msvc

I have used Visual Studio 2015 which seems to be named also "Microsoft Visual Studio 14.0" and the compiler prints the version number 19.00.23506.

It would be interesting to have numbers for different versions of Visual Studio compiler, although I understand that it would require more time and it might be not applicable for your project if you are using C++11 features intensively.

We have performed some tests in the past, which showed that VS2010 generates faster code than follow versions, although VS2015 have not been available at that time:
http://dev.opencascade.org/index.php?q=node/903

OCCT Compilation Times:
MSVC: 104 minutes
MinGW-w64 with "-O3": 137 minutes

The compilation numbers look a little bit strange to me, since them are quite big and greater than I have been experienced. Which hardware configuration has been used for testing?

On my home workstation with AMD FX8350 CPU the MinGW compiler generated code significantly faster than VS2013. It was just 18 minutes for Release x64 build on MinGW (of course using 8 threads)!

08Commenter-1

I also would have been interested in a comparison with MSVC 2010 and I have spent some time trying to install MSVC 2010 Express and upgrade it to a 64 bit compiler, but I didn't manage in reasonable time (there is conflicting software on my computer). Since we definitely want to use C++11 features, this would anyway be a very theoretical comparison.

The compilation times here are so high, because I have been doing serial builds.

09Author

The compilation times here are so high, because I have been doing serial builds.

From my understanding, multi-threaded build works better with gcc - the CPU load of 8 cores was higher than with msvc. I even have system hardware crashes due to CPU high temperature, which have not happened before with Visual Studio - so I have to disable silent mode in BIOS to build using MinGW.

Just my 50 cents to this comparison.