<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi All,<br>
<br>
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(<a class="moz-txt-link-freetext" href="http://review.source.kitware.com/#/c/14730/">http://review.source.kitware.com/#/c/14730/</a>). I'd like to
know if others agree that this is a reasonable change? Thoughts
and/or comments?<br>
<br>
Thanks<br>
Burlen<br>
<br>
<br>
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.<br>
<br>
edison03:/usr/common/graphics/ParaView/builds/PV-4.1.0$ldd
bin/pvserver<br>
linux-vdso.so.1 => (0x00002aaaaaaab000)<br>
<font color="#ff0000"> libGLU.so.1 =>
/usr/lib64/libGLU.so.1 (0x00002aaaaab05000)<br>
libSM.so.6 => /usr/lib64/libSM.so.6
(0x00002aaaaad8a000)<br>
libICE.so.6 => /usr/lib64/libICE.so.6
(0x00002aaaaaf93000)<br>
libX11.so.6 => /usr/lib64/libX11.so.6
(0x00002aaaab1b0000)<br>
libXext.so.6 => /usr/lib64/libXext.so.6
(0x00002aaaab4ee000)<br>
libGL.so.1 => /usr/lib64/libGL.so.1
(0x00002aaaab700000)<br>
</font> libm.so.6 => /lib64/libm.so.6 (0x00002aaaab986000)<br>
libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabc00000)<br>
libpthread.so.0 => /lib64/libpthread.so.0
(0x00002aaaabe04000)<br>
libstdc++.so.6 =>
/opt/gcc/default/snos/lib64/libstdc++.so.6 (0x00002aaaac021000)<br>
libgcc_s.so.1 =>
/opt/gcc/default/snos/lib64/libgcc_s.so.1 (0x00002aaaac33d000)<br>
libc.so.6 => /lib64/libc.so.6 (0x00002aaaac554000)<br>
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)<br>
<font color="#ff0000"> libglapi.so.0 =>
/usr/lib64/libglapi.so.0 (0x00002aaaac8cb000)<br>
libXdamage.so.1 => /usr/lib64/libXdamage.so.1
(0x00002aaaacb23000)<br>
libXfixes.so.3 => /usr/lib64/libXfixes.so.3
(0x00002aaaacd26000)<br>
libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1
(0x00002aaaacf2c000)<br>
libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0
(0x00002aaaad12f000)<br>
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1
(0x00002aaaad345000)<br>
libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0
(0x00002aaaad54b000)<br>
libxcb.so.1 => /usr/lib64/libxcb.so.1
(0x00002aaaad74e000)<br>
libXau.so.6 => /usr/lib64/libXau.so.6
(0x00002aaaad96a000)<br>
libdrm.so.2 => /usr/lib64/libdrm.so.2
(0x00002aaaadb6e000)</font><br>
libuuid.so.1 => /lib64/libuuid.so.1 (0x00002aaaadd7a000)<br>
librt.so.1 => /lib64/librt.so.1 (0x00002aaaadf7f000)<br>
<br>
</body>
</html>