[vtk-developers] X11 and libGL always linked

Andy Bauer andy.bauer at kitware.com
Sun Mar 16 10:29:33 EDT 2014


Hi Burlen,

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.

Regards,
Andy


On Fri, Mar 14, 2014 at 5:31 PM, Burlen Loring <burlen.loring at gmail.com>wrote:

>  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)
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140316/65ff8e67/attachment-0002.html>


More information about the vtk-developers mailing list