I’m testing VTK (9.2.2) with MESA.
VTK is from my own compilation, with standard settings.
I’m under Windows 11, and to test MESA I just put “opengl32.dll” (and dependencies) besides my EXE.
With MESA from “fdossena.com”, all seams to work normally (with the expected performance drop).
With a more recent MESA from “pal1000 · GitHub”, VTK crashes instantly when trying to instantiate a graphic pipe (RenderWindow + Renderer).
Both MSVC and MINGW are crashing.
I’ve not tested all versions, but most recent ones.
Do you guy have any idea why VTK is not working with this specific MESA binaries ?
Thanks !
First, MinGW and MinGW64 are different projects. So, please, double check you’re using the same compiler as used to build the MESA binaries. The same applies to MSVC. Up to VS2015, the VS versions are not binary compatible with each other.
That kind of thing makes me nervous. I advice against doing that. When building with VS, you should use the DLL whose corresponding .LIB library was used during linking. When building with MinGW or MinGW’s GCC, you should use the DLL whose corresponding .A library was used during linking. These .LIB and .A files look like static libraries, but when they accompany DLLs, they are known as stub or import libraries in Windows for they don’t have the actual symbol implementation in them. Differences in C++ name mangling between compilers may result in symbols not being found with an ensuing crash. This is a Windows thing (bad bad Microsoft ). In Linux you just need the .H and the .SO to link a binary against a given library.
I should have be more precise on the context.
I want to use MESA as a drop down replacement for local machine implementation, on remote client workstation, when it is necessary (for example under Parallels Desktop).
It is not possible/convenient to provide the customer with a totally different software, this is why I’m using the “opengl32.dll besides EXE method”.
I’m compiling VTK with VS2022, so I understand why MinGW releases cannot work.
But MSVC should work …
I should try to recompile MESA MSVC with the same toolchain than VTK to be sure.
But since dossena build works fine, it’s not so urgent.
It’s a fair bit of complex cmake actions to figure out, but here’s the steps: paraview, mesa and the launcher app are built by the superbuild, then the packaging step renames paraview to paraview_real, renames the launcher to paraview, and puts the mesa libraries in a subdirectory. Then, when paraview (which is actually the launcher) is started with the --mesa argument, the environment is modified so the mesa opengl libraries are found first.
I don’t think this is necessary. I believe just linking VTK against the MESA DLLs you intend to deploy is enough. I’m supposing the MESA binaries were built with VS2015 or later.
I advice against doing that. When building with VS, you should use the DLL whose corresponding .LIB library was used during linking. When building with MinGW or MinGW’s GCC, you should use the DLL whose corresponding .A library was used during linking. These .LIB and .A files look like static libraries, but when they accompany DLLs, they are known as stub or import libraries in Windows for they don’t have the actual symbol implementation in them. Differences in C++ name mangling between compilers may result in symbols not being found with an ensuing crash. This is a Windows thing (bad bad Microsoft 
). In Linux you just need the .H and the .SO to link a binary against a given library.