Hello. Sorry for the late response. I didn’t like that much. You do you mean by upgrade? You have to configure and build VTK 9.1 from scratch. If you’re reusing something from VTK 9.0.1 (e.g. build directory, libraries, CMakeLists.txt, etc.) you will likely run into problems. Forget VTK 9.0.1.
Hello,
Overkill indeed.
This is how to set the -fcommon flag properly:
Or, if command lines suit you: cmake (...) -DCMAKE_CXX_FLAGS=-fcommon -DCMAKE_C_FLAGS=-fcommon.
regards,
Paulo
1 Like
I, have tried many things to build vtk using MINGW64. but getting below error.
anybody can help me or any one can share the installed vtk folder which is build using the MINGW64.
Hi @PRJ
MINGW64 is not officially supported by VTK, why not using visual studio compilers ?
Hi @mwestphal
We have project which are build using MINGW64 and when I use vtk libraries which are build using visual studio compiler, it gives linkers errors.
Hello,
VTK 9 now has script parsing capabilities enabled by the ExprTK engine. The entire ExprTK library consists of a single .h file. As such, object files compiled from code including it tend to have a large number of symbols. Compiling in debug mode tend to exceed the maximum number of symbols, hence the error.
One solution to that is to build VTK in debug mode enabling optimization options in CMAKE_CXX_FLAGS_DEBUG, starting with -O1 and increasing to -O2, -O3, etc. until you get it right. Optimization flags decrease the number of symbols in the resulting object file.
take care,
Paulo
Hello, Mathieu,
That’s true, but, for my case, one of my projects uses many other libraries which are difficult to find precompiled with VS. For pratical reasons, I opted for MinGW64 because there are public repositories of precompiled DLLs that can be managed with the pacman tool in MSYS2, which is much like pip, conda, npm, Maven, Conan and others for other languages and tool sets.
best,
Paulo
That make sense, but then adding a CI in VTK for MinGW64 would make this officialy supported and more viable.
How can one do that?
The CI in VTK is handled using gitlab CI. One can add a job with new parameters, new way to build VTK and such.
Of course, in your case you would need to add MinGW64 as a new dependency, but that should not be too hard since it is all generated with a Dockerfile, also present in the CI.
All of that can be done from your MR (except for uploading the new docker image to dockerhub)
You will probably need help from Kitware folks to get it over the line but that is pretty doable.
1 Like
Hi @Paulo_Carvalho ,
Thanks , that too big file related issues solved . and project build up to 79% but still some errors are getting. I’m attaching screenshot of errors which are getting, can you help me to solve this.
Hello,
It seems to me to be some definition clash of the STRICT symbol (see https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8659, which was not merged). To solve that, try:
- If you don’t need NetCDF, disable it in VTK configuration. (preferable)
- If you do need it and can’t wait, try tweaking the file
ThirdParty/libproj/vtk_libproj.h.inin VTK source code by adding these lines somehere in the first 10-30 lines of the file and rebuild VTK:
// Prevent interference with enum in proj/util.hpp.
// https://github.com/OSGeo/PROJ/pull/2949
#ifdef STRICT
#undef STRICT
#endif
source: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8659/diffs
Apparently, the fix to the offending third party library has been merged according to https://github.com/OSGeo/PROJ/pull/2949 . Maybe an update is missing in VTK source to receive the fix.
take care,
Paulo
This might point you in the right direction for solving the dllimport attribute problem.
https://lists.gnu.org/archive/html/bug-gettext/2016-09/msg00004.html
Is VTKIONETCDF_EXPORT defined in vtkIONetCDFModule.h?
Thanks @Paulo_Carvalho
2 nd Option worked for me. now I’m able to build the vtk using
mingw.
1 Like
You’re wellcome, friend. But remember: everytime you download a new VTK source code, you have to ammend the offending file again until the VTK dependency is updated to receive the fix.
best,
Paulo
That’s true, but adding mingw toolchains to the CI machines is probably non-trivial (unless there’s some way to just download and extract a suitable toolchain and environment). Note that patches to support MinGW are accepted; it’s just that testing it is a community effort.
1 Like
Mingw-w64 | Microsoft Learn maybe ?
That doesn’t seem viable since getting things is:
After the basic installation of MSYS2, you will need to install a few additional packages for software development, for example, for x64:
We need a “portable” mingw toolchain for CI to just extract and run. System-wide installers are not useful.
Hello, Ben,
I suggest you to try MSYS2, which has an instaler. First, you install it (e.g. in C:\msys2). Then, run pacman -S mingw-w64-x86_64-toolchain in its command line interface to install MinGW64 in it. After that, just zip the MSYS2 installation folder and unpack it where you like. Finally, you likely need to configure CI/CD script to put the toolchain executables and libraries in PATH (D:\mySoftwaresPortables\msys64\mingw64\bin and D:\mySoftwaresPortables\msys64\mingw64\lib), for example, supposing you unzipped the MSYS2 installation directory to D:\mySoftwaresPortables\. That worked for me. That way you can have a working MinGW64 in your CI/CD environment without the need for a system-wide installation.
best,
PC