[vtk-developers] X11 and libGL always linked

Burlen Loring burlen.loring at gmail.com
Fri Mar 14 17:31:41 EDT 2014


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?

Thanks
Burlen


for the curious here's ldd on the pvserver exec produced by default, 
this build has X11 disabled and OSMesa enabled so none of the X11 or GL 
stuff should be linked. OSMesa isn't listed because its built as a 
static library.

edison03:/usr/common/graphics/ParaView/builds/PV-4.1.0$ldd bin/pvserver
         linux-vdso.so.1 =>  (0x00002aaaaaaab000)
         libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002aaaaab05000)
         libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002aaaaad8a000)
         libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002aaaaaf93000)
         libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002aaaab1b0000)
         libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002aaaab4ee000)
         libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002aaaab700000)
         libm.so.6 => /lib64/libm.so.6 (0x00002aaaab986000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabc00000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaabe04000)
         libstdc++.so.6 => /opt/gcc/default/snos/lib64/libstdc++.so.6 
(0x00002aaaac021000)
         libgcc_s.so.1 => /opt/gcc/default/snos/lib64/libgcc_s.so.1 
(0x00002aaaac33d000)
         libc.so.6 => /lib64/libc.so.6 (0x00002aaaac554000)
         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
         libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002aaaac8cb000)
         libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002aaaacb23000)
         libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002aaaacd26000)
         libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002aaaacf2c000)
         libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002aaaad12f000)
         libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002aaaad345000)
         libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 
(0x00002aaaad54b000)
         libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002aaaad74e000)
         libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002aaaad96a000)
         libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002aaaadb6e000)
         libuuid.so.1 => /lib64/libuuid.so.1 (0x00002aaaadd7a000)
         librt.so.1 => /lib64/librt.so.1 (0x00002aaaadf7f000)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtk-developers/attachments/20140314/5a2cbbbc/attachment.html>


More information about the vtk-developers mailing list