[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