# MESA ?
**URL:** https://discourse.vtk.org/t/mesa/13381
**Category:** Support
**Created:** [February 24, 2024, 12:38pm UTC](https://discourse.vtk.org/t/mesa/13381 "2024-02-24T12:38:36Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Olivier](https://discourse.vtk.org/u/Olivier)
#### Post date: [February 24, 2024, 12:38pm UTC](https://discourse.vtk.org/t/mesa/13381/1 "2024-02-24T12:38:36Z")
Hi friends,
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](http://fdossena.com)”, all seams to work normally (with the expected performance drop).
With a more recent MESA from “[pal1000 · GitHub](http://github.com/pal1000)”, 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 !
---
### Author:  [@Paulo\_Carvalho](https://discourse.vtk.org/u/Paulo_Carvalho)
#### Post date: [February 24, 2024, 9:47pm UTC](https://discourse.vtk.org/t/mesa/13381/2 "2024-02-24T21:47:03Z")
Hello,
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.
> [@Olivier](#):
>
> I just put “opengl32.dll”
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.
best,
PC
---
### Author:  [@Olivier](https://discourse.vtk.org/u/Olivier)
#### Post date: [February 26, 2024, 8:21am UTC](https://discourse.vtk.org/t/mesa/13381/3 "2024-02-26T08:21:12Z")
Thanks Paulo for your answer.
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.
Thanks again Paulo.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [February 26, 2024, 12:58pm UTC](https://discourse.vtk.org/t/mesa/13381/4 "2024-02-26T12:58:24Z")
I just want to mention that I’m using [pal1000 · GitHub](http://github.com/pal1000) msvc version without issues in github actions for a VTK project.
---
### Author:  [@Aron\_Helser](https://discourse.vtk.org/u/Aron_Helser)
#### Post date: [February 26, 2024, 3:39pm UTC](https://discourse.vtk.org/t/mesa/13381/5 "2024-02-26T15:39:46Z")
I also want to point out that ParaView uses this strategy, with the `launchers` application provided in the superbuild: [https://gitlab.kitware.com/paraview/paraview-superbuild/-/tree/master/launchers](https://gitlab.kitware.com/paraview/paraview-superbuild/-/tree/master/launchers)
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.
---
### Author:  [@Paulo\_Carvalho](https://discourse.vtk.org/u/Paulo_Carvalho)
#### Post date: [February 26, 2024, 5:30pm UTC](https://discourse.vtk.org/t/mesa/13381/6 "2024-02-26T17:30:23Z")
Hello,
> [@Olivier](#):
>
> I should try to recompile MESA MSVC with the same toolchain than VTK to be sure.
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.
best,
PC