[vtk-developers] X11 and libGL always linked

[Marcus D. Hanwell]

On Fri, Mar 14, 2014 at 5:31 PM, Burlen Loring <burlen.loring at gmail.com> wrote:
> Hi All,
>
> While installing the past two PV releases I've noticed that VTK is linking
> in X11 and libGL when using OSMesa, which is acheived by VTK_USE_X=OFF and
> VTK_OPENGL_HAS_OSMESA=ON. This is one a of a number of issues that is making
> statically linked PV executables on the Cray painful. I think that the
> history of this is that this was useful in the past when mangled Mesa was
> used but currently this is the wrong thing to do because the extension
> manager can only use one or the other as GetProcAddress function is selected
> at compile time, and at run time it's used indiscriminatly regardless of
> actual context type(OSMesa context or other GL context) so there's currently
> no chance that you could safely use both. Also, linking both libraries can
> create a link time race condition between libGL and libOSMesa that depends
> on link order(eg both are .so's or .a's). I think that in a single build VTK
> needs to carefully use either libGL or OSMesa, but not both, and that
> linking against X11 should be avoided when VTK_USE_X11=OFF.  I've tracked
> the X11 library inclusion down, it's coming from FindOpenGL.cmake, which
> appends X11 libraries to OPENGL_LIBRARIES indiscriminately when X11 is
> found. I've pushed a patch (which needs a careful review and some more
> testing) onto gerrit that explicitly separates OpenGL and OSMesa use in
> VTK(http://review.source.kitware.com/#/c/14730/). I'd like to know if others
> agree that this is a reasonable change? Thoughts and/or comments?
>
I started looking at this briefly before I left, and hit the same
thing Andy mentioned (having to clear OPENGL_gl_LIBRARY to get a
working OSMesa). It would be great to improve this part of the build
system (I wasn't aware of all the history, but assumed it had
something to do with mangled mesa).

I will try to find some time to take a closer look at the proposed
patch in the next few days, and always wanted to loop back to this
logic since modularization as it appeared overly complex but we also
wanted to remain cautious to breaking OSMesa/other build
configurations and it was largely ported from previous logic.

Marcus