<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Thanks Guys! I appreciate your eyes on
      it.<br>
      <br>
      As you point out clearing OPENGL_gl_LIBRARY should prevent libGL
      dependency and link order issues. In my builds I have got into the
      habit of setting it to libOSMesa which does the same. In any case
      this doesn't prevent the X11 libs from being linked. in
      FindOpenGL.cmake that ships with cmake, X11 libs are always tacked
      onto OPENGL_LIBRARIES, which is used in
      Rendering/OpenGL/CMakeLists. <br>
      <br>
      my main motivation in digging into these issues is to address a PV
      performance issue on NERSC's Crays. Users found that PV start-ups
      were sometimes taking a very long time (eg 30 min for 48 way
      parallel run). We tracked the issue to the file system and PV's
      use of shared libraries. With PV there are many shared library
      dependencies (~200), and when parallel pvserver's startup they all
      hit the file system at the same time all opening these shared
      library files. When I make static executables startup time is
      reduced reliably to a few seconds. I admit static executables are
      an extreme measure, and I hit a handful of cmake/pv specific cmake
      related issues doing it that won't be easy to address. However,
      it's probably OK performance wise to settle for "as static as
      possible", and getting the list of shared library dependencies
      from ~200 to ~10 should make for a big improvement. Removing those
      X11 deps when using OSMesa gets us "as static as possible" and
      without too much effort. <br>
      <br>
      Burlen<br>
      <br>
      On 03/17/2014 08:03 AM, David E DeMarle wrote:<br>
    </div>
    <blockquote
cite="mid:CANjZAi9KWWwZgw_TLNyc1_H16F5AXa_p-aaNP_KST4gc_vHxfQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">I'll take a close look at this too.
        <div><br>
        </div>
        <div>Like Andy said, we do get by for example in ParaView's
          cross compiling super build, but I'm all in for making it
          easier in practice to get VTK and ParaView up and running in
          HPC contexts.</div>
        <div><br>
        </div>
        <div>Thanks as always Burlen!
          <div><br>
          </div>
        </div>
      </div>
      <div class="gmail_extra"><br clear="all">
        <div>David E DeMarle<br>
          Kitware, Inc.<br>
          R&D Engineer<br>
          21 Corporate Drive<br>
          Clifton Park, NY 12065-8662<br>
          Phone: 518-881-4909</div>
        <br>
        <br>
        <div class="gmail_quote">On Mon, Mar 17, 2014 at 10:06 AM,
          Marcus D. Hanwell <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="">On Fri, Mar 14, 2014 at 5:31 PM, Burlen Loring
              <<a moz-do-not-send="true"
                href="mailto:burlen.loring@gmail.com">burlen.loring@gmail.com</a>>
              wrote:<br>
            </div>
            <div class="">> Hi All,<br>
              ><br>
              > While installing the past two PV releases I've
              noticed that VTK is linking<br>
              > in X11 and libGL when using OSMesa, which is acheived
              by VTK_USE_X=OFF and<br>
              > VTK_OPENGL_HAS_OSMESA=ON. This is one a of a number
              of issues that is making<br>
              > statically linked PV executables on the Cray painful.
              I think that the<br>
              > history of this is that this was useful in the past
              when mangled Mesa was<br>
              > used but currently this is the wrong thing to do
              because the extension<br>
              > manager can only use one or the other as
              GetProcAddress function is selected<br>
              > at compile time, and at run time it's used
              indiscriminatly regardless of<br>
              > actual context type(OSMesa context or other GL
              context) so there's currently<br>
              > no chance that you could safely use both. Also,
              linking both libraries can<br>
              > create a link time race condition between libGL and
              libOSMesa that depends<br>
              > on link order(eg both are .so's or .a's). I think
              that in a single build VTK<br>
              > needs to carefully use either libGL or OSMesa, but
              not both, and that<br>
              > linking against X11 should be avoided when
              VTK_USE_X11=OFF.  I've tracked<br>
              > the X11 library inclusion down, it's coming from
              FindOpenGL.cmake, which<br>
              > appends X11 libraries to OPENGL_LIBRARIES
              indiscriminately when X11 is<br>
              > found. I've pushed a patch (which needs a careful
              review and some more<br>
              > testing) onto gerrit that explicitly separates OpenGL
              and OSMesa use in<br>
              > VTK(<a moz-do-not-send="true"
                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<br>
              > agree that this is a reasonable change? Thoughts
              and/or comments?<br>
              ><br>
            </div>
            I started looking at this briefly before I left, and hit the
            same<br>
            thing Andy mentioned (having to clear OPENGL_gl_LIBRARY to
            get a<br>
            working OSMesa). It would be great to improve this part of
            the build<br>
            system (I wasn't aware of all the history, but assumed it
            had<br>
            something to do with mangled mesa).<br>
            <br>
            I will try to find some time to take a closer look at the
            proposed<br>
            patch in the next few days, and always wanted to loop back
            to this<br>
            logic since modularization as it appeared overly complex but
            we also<br>
            wanted to remain cautious to breaking OSMesa/other build<br>
            configurations and it was largely ported from previous
            logic.<br>
            <span class="HOEnZb"><font color="#888888"><br>
                Marcus<br>
              </font></span>
            <div class="HOEnZb">
              <div class="h5">_______________________________________________<br>
                Powered by <a moz-do-not-send="true"
                  href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
                <br>
                Visit other Kitware open-source projects at <a
                  moz-do-not-send="true"
                  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 moz-do-not-send="true"
                  href="http://www.vtk.org/mailman/listinfo/vtk-developers"
                  target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>