# \[solved\] Compiling superbuild does not produce all executables
**URL:** https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308
**Category:** ParaView Support
**Created:** [January 10, 2020, 3:52pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308 "2020-01-10T15:52:40Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [January 10, 2020, 3:52pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/1 "2020-01-10T15:52:40Z")
Working with the superbuild of Paraview 5.7.0 with the tarball as source. I have _independently_ installed pv on two computers in a network that tap from the same grand set of programs and shared libraries. Also the so-called ‘external settings’ in cache of ccmake (file CMakeCache.txt) are the same.
I am at loss finding out why, in one of the two systems, the compilation and install does create the executables **pvdataserver** , **pvrenderserver** and **pvserver** and does not generate **hydra\_pmi\_proxy** , **mpiexec** and **paraview.**
I have redirected the stdout and stderr of the compilation process (`make -j8 2>&1 | tee logfile`) to a file and, for both computers, `grep -i "error" `does not report errors occurring. I can’t seem to find a reason why such important files are not created in equal conditions (save oversights that may become evident at some point). This should depend on some miss that I fail to see.
Any tip and directions to clear up the confusion following from this is welcome.
Thanks in advance for it.
---
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [January 11, 2020, 9:43am UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/2 "2020-01-11T09:43:46Z")
The fact that a `paraview` executable has not been build can be an indication that the **rendering engine** selected (egl, qt5, mesa, omesa, …) does not prescribe this. On second looks with a fresh pair of eyes, it appeared indeed that the two sets of build variables were not the same, as claimed earlier. They differed for the rendering engine: `ENABLE_qt5=ON` creates `paraview` and `ENABLE_egl=ON` does not. So the report above was an XFAIL situation, and human error once again. Hope this helps.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 13, 2020, 12:40pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/3 "2020-01-13T12:40:15Z")
Just a point to raise. You seems to confuse the Rendering engine and Qt5.
Qt5 is not a rendering engine, it is just the UI library we use to build the ParaView executable. Without it, no paraview executable.
It so happens that certain rendering engine (egl) are not compatible with Qt5.
---
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [January 13, 2020, 2:25pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/4 "2020-01-13T14:25:58Z")
Thanks @mwestphal for clarifying this. Then here is something to fix/debate in [https://gitlab.kitware.com/paraview/paraview-superbuild/blob/master/README.md](https://gitlab.kitware.com/paraview/paraview-superbuild/blob/master/README.md), where it is stated that (boldface is mine)
> ParaView supports multiple **rendering engines** including `egl` , `mesa` , `osmesa` , and `qt5` . All of these are incompatible with each other. If none of these are chosen, a UI-less ParaView will be built (basically just `pvpython` ). On Windows and macOS, only the `qt5` **rendering engine** is available.
which guided my associations
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 14, 2020, 11:24am UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/5 "2020-01-14T11:24:16Z")
@ben.boeckel @utkarsh.ayachit : What would be the right formulation here ?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [January 14, 2020, 3:21pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/6 "2020-01-14T15:21:55Z")
Probably something like
> ParaView supports multiple rendering engines including OpenGL and EGL (mutually exclusive). These may be used by different frontends including Mesa, OSMesa, or Qt5 (each mutually exclusive). Without Qt5, a UI-less ParaView will be built and Qt5 is the only supported frontend for Windows and macOS.
---
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [January 14, 2020, 6:13pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/7 "2020-01-14T18:13:47Z")
Please note that at generation ccmake throws an error when Qt\_5 and EGL are selected at the same time.
> CMake Error at CMakeLists.txt:182 (message):
> **Cannot enable EGL and Qt at the same time.**
> Call Stack (most recent call first):
> superbuild/CMakeLists.txt:151 (superbuild\_sanity\_check)
It is then not just a question of editing the readme file, but also of coding the build rules accordingly.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [January 14, 2020, 8:20pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/8 "2020-01-14T20:20:22Z")
Oh, yes. Qt5 requires OpenGL; EGL is not supported. That should be included in the reword in my comment.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2020, 9:51am UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/9 "2020-01-17T09:51:24Z")
@XavierStuvw : Do you think you could take care of this rewording ? That would be very nice of you.
---
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [January 17, 2020, 1:39pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/10 "2020-01-17T13:39:33Z")
Happy to help, but it’s nothing more than some linguistic editing. You know what happens under the hood and it up to the developers’ responsibility to endorse it. This having been said…
> Paraview supports either OpenGL or EGL as rendering engine. The frontends supported are Qt5 for OpenGL, and Mesa and OSMesa for both OpenGL and EGL. Qt5 is the only frontend for Windows and macOS; frontends are mutually exclusive for Linux. A ParaView built without Qt5 will have no user interface.
Is this nice enough? Please feel free to edit.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2020, 1:46pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/11 "2020-01-17T13:46:56Z")
Perfect. I also meant for you to contribute to contribute on our gitlab, as ParaView is an open source project open to external contribution as well.
Here is the correction :
[https://gitlab.kitware.com/paraview/paraview-superbuild/merge\_requests/690](https://gitlab.kitware.com/paraview/paraview-superbuild/merge_requests/690)
---
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [January 17, 2020, 1:53pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/12 "2020-01-17T13:53:27Z")
You have been quick. I also thought of this
> Paraview supports either OpenGL or EGL as rendering engine. OpenGL accepts either Qt5, Mesa or OSMesa as frontend, while EGL accepts either Mesa or OSMesa. For Windows and macOS only the pair OpenGL/Qt5 is permitted. A ParaView built without Qt5 will have no user interface.
I will consider contributing directly in the future as my familiarity with Paraview grows. For the moment my primary interest is to get it working in parallel: [vtkSocketCommunicator errors: "Could not receive tag" and "Endian handshake failed"](https://discourse.paraview.org/t/vtksocketcommunicator-errors-could-not-receive-tag-and-endian-handshake-failed/3350) – with apologies for the shameless promotion of my pains.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [February 25, 2020, 8:09am UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/13 "2020-02-25T08:09:06Z")
A consensus has not been found. I have closed the MR.
---
### Author:  [@XavierStuvw](https://discourse.paraview.org/u/XavierStuvw)
#### Post date: [February 25, 2020, 12:47pm UTC](https://discourse.paraview.org/t/solved-compiling-superbuild-does-not-produce-all-executables/3308/14 "2020-02-25T12:47:10Z")
@mwestphal It would then be desirable that, beyond terminological questions, the README of the Superbuild file explains which logic is implemented in the error messages. So users can back trace their errors and, forewarned, avoid them forearmed. Maybe it is already there, but a double check would do no harm, and perhaps a lot of good.
* * *
To the future reader. I had edited the post title believing it had been [solved]. In fact the discussions on the merge requests in the issue tracker have proven more controversial then expected. Please disregard that [solved] and proceed at your own risk.