<div dir="ltr"><div><div>Hi Burlen,<br><br></div>In the past when I used OSMesa I always set OPENGL_gl_LIBRARY to empty. I didn't test it out but does that still pull in the X11 libraries with those settings? From the way you describe it it seems like that may be the desired effect. It's not exactly straight-forward on how to do this the proper way though without having to dig deep into code.<br>
<br></div>Regards,<br>Andy<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 5:31 PM, Burlen Loring <span dir="ltr"><<a href="mailto:burlen.loring@gmail.com" target="_blank">burlen.loring@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div 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 href="http://review.source.kitware.com/#/c/14730/" target="_blank">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>
  </div>

<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><br></div>