joeh
September 20, 2019, 1:10pm
21
Utkarsh,
I have finished the clean builds and while it is now creating the new mesa directory inside of lib and putting libGL.so and other libraries in there, when paraview is run with
paraview-mesa paraview --backend llvmpipe --print
paraview is still not using that libGL.so that is now in the lib/mesa directory and is instead still attempting to use a nonexistant nvidia driver (and thus failing). Your distributed binaries do not have this problem, and correctly use the Mesa compiled lib. Why is paraview ignoring the library that it built and installed?
Thanks,
Joe
Alright, next step. Mind attaching (or emailing) the LD_DEBUG=libs complete output? Let’s see which libGLX is getting loaded and why.
joeh
September 20, 2019, 3:57pm
23
Utkarsh,
Here is the interesting portion, I think
51359: find library=libGLX.so.0 [0]; searching
51359: search path=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib:/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib:/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib64 (RPATH from file /p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/paraview)
51359: trying file=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib/libGLX.so.0
51359: trying file=/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib/libGLX.so.0
51359: trying file=/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib64/libGLX.so.0
51359: search path=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib/mesa (LD_LIBRARY_PATH)
51359: trying file=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib/mesa/libGLX.so.0
51359: search cache=/etc/ld.so.cache
51359: trying file=/lib64/libGLX.so.0
51359:
51359: find library=libOpenGL.so.0 [0]; searching
51359: search path=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib:/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib:/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib64 (RPATH from file /p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/paraview)
51359: trying file=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib/libOpenGL.so.0
51359: trying file=/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib/libOpenGL.so.0
51359: trying file=/usr/cta/DAAC/build/PV/Build_5.7.0-RC4_mesa_mpich/install/lib64/libOpenGL.so.0
51359: search path=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib/mesa (LD_LIBRARY_PATH)
51359: trying file=/p/app/DAAC/paraview/5.7.0-RC4_mesa_mpich/bin/../lib/mesa/libOpenGL.so.0
51359: search cache=/etc/ld.so.cache
51359: trying file=/lib64/libOpenGL.so.0
but I have attached the full output as well.
test_run_output.txt (250.6 KB)
Thanks,
Joe
joeh
September 20, 2019, 4:03pm
24
Utkarsh,
libGLX.so.0 is not in the lib or lib/mesa directories
libGL.so and libGL.so.1 is in lib/mesa but is not being used for
Thanks,
Joe
right! so mesa build it not building libGLX etc. correctly. Are those files present in the superbuild build directory at all?
joeh
September 20, 2019, 4:09pm
27
Utkarsh,
Attached is a list of the libraries found in lib and lib/mesa.
Thanks,
Joe
library_list.txt (69.7 KB)
joeh
September 20, 2019, 4:21pm
28
I checked the entire superbuild directory and the only files being built are
libGL.la
No libGLX.so.0 or libOpenGL.so.0 is being built
but
libGL.so
are also what is found in your binary distribution for linux, libOpenGL.so.0 and libGLX.so.0 are also not found in your binary distribution for RC4 either.
Thanks,
Joe
joeh
September 20, 2019, 4:27pm
29
Utkarsh here are the contents of
as you requested.
[joeh@centennial20 bin]$ pwd
[joeh@centennial20 bin]$ ls -ld …/lib/mesa/*
mind attaching the LD_DEBUG=libs output from the paraview.org binary? Let’s see where things are different, since looks like the two packages are identical in contents.
joeh
September 20, 2019, 7:05pm
31
Utkarsh,
Here is the most interesting part
16344: find library=libGL.so.1 [0]; searching
16344: search path=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib (RPATH from file /p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/paraview)
16344: trying file=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib/libGL.so.1
16344: search path=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib/mesa (LD_LIBRARY_PATH)
16344: trying file=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib/mesa/libGL.so.1
16344:
16344: find library=libGLU.so.1 [0]; searching
16344: search path=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib (RPATH from file /p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/paraview)
16344: trying file=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib/libGLU.so.1
16344: search path=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib/mesa (LD_LIBRARY_PATH)
16344: trying file=/p/app/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/bin/../lib/mesa/libGLU.so.1
16344: search cache=/etc/ld.so.cache
16344: trying file=/lib64/libGLU.so.1
And here is the whole file attached.
Thanks,
Joe
test_run_output_kitware_build.txt (302.0 KB)
Interesting indeed! I think I know what the issue is, but just one more thing – can you post the result from readelf -d libvtkglew-pv5.7.so.1 from both binaries. Kitware’s should have a header as follows, I suspect your build is depending on libGLX instead.
> readelf -d libvtkglew-pv5.7.so.1
Dynamic section at offset 0x9dd50 contains 28 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libGL.so.1]
0x0000000000000001 (NEEDED) Shared library: [libGLU.so.1]
0x000000000000000e (SONAME) Library soname: [libvtkglew-pv5.7.so.1]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN:$ORIGIN/../lib]
....
joeh
September 20, 2019, 7:40pm
33
Utkarsh,
Here you go. First from my build.
/usr/cta/DAAC/paraview/5.7.0-RC4_mesa_mpich/lib
[joeh@centennial01 lib]$ readelf -d libvtkglew-pv5.7.so.1
Dynamic section at offset 0x9cd50 contains 28 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libGLX.so.0]
0x0000000000000001 (NEEDED) Shared library: [libOpenGL.so.0]
0x000000000000000e (SONAME) Library soname: [libvtkglew-pv5.7.so.1]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
...
Then from the kitware build
[joeh@centennial01 lib]$ pwd
/usr/cta/DAAC/build/ParaView-5.7.0-RC4-MPI-Linux-Python3.7-64bit/lib
[joeh@centennial01 lib]$ readelf -d libvtkglew-pv5.7.so.1
Dynamic section at offset 0x9dd50 contains 28 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libGL.so.1]
0x0000000000000001 (NEEDED) Shared library: [libGLU.so.1]
0x000000000000000e (SONAME) Library soname: [libvtkglew-pv5.7.so.1]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN:$ORIGIN/../lib]
...
Thanks,
Joe
joeh
September 20, 2019, 7:44pm
34
Utkarsh,
Here is it in a file as it seems to have somehow escaped in the editor.
Thanks,
Joe
readelf_output.txt (3.5 KB)
exactly as I suspected, the ParaView build in the Superbuild is finding and using system OpenGL rather than the OpenGL from mesa the Superbuild built. Your system OpenGL is old and hence CMake switches to using the old-style OpenGL libraries. Next, I’ll figure out what needs to change on the Superbuild side to fix this.
What linux type/version are you building on? I’ll see if I can reproduce this behavior in a docker container and make debugging easier.
joeh
September 20, 2019, 9:48pm
36
Utkarsh,
The system is running “Red Hat Enterprise Linux Server” version 7.6.
Thanks,
Joe
@joeh , can you try the attached patch please? It’ll need to be applied to the Superbuild.
My observations are as follows:
the issue arises when using superbuild (SB) to build binaries with mesa enabled on a system that has GLVND-based OpenGL. That’s the reason why we are seeing this when the binary is built on RHEL:7.6 (your machine) but not on centos:6 (paraview.org binaries). (The former uses GLVND for OpenGL by default, while the latter does not.)
Mesa that the SB builds is without glvnd. Thus, it only builds libGL (old ABI) and not libGLX, libOpenGL etc (new GLVND-based ABI).
When building on a system with GLVND, ParaView ends up finding and linking directly with the GLVD-based libraries i.e libGLX, libOpenGL etc. However, when building on non-GLVD based system, ParaView finds and links using old OpenGL ABI i.e. libGL. Thus, in former case the Mesa libGL will never be loaded while in the latter case, it will be loaded correctly if found in search path – the mechanism ParaView has traditionally relied on for the runtime mesa switching.
In summary, we need to fix how the runtime mesa-dispatch is expected to work when using GLVND-based OpenGL interfaces. For 5.7, forcing use of legacy OpenGL interfaces when mesa is enabled (as done in attached patch), should suffice.
joeh
September 23, 2019, 11:17am
38
Utkarsh,
The patch worked, my ParaView 5.7.0-RC4 version, built with the patched superbuild, is now behaving the same as the Kitware built binaries and properly loading the version of Mesa version it built in libGL.so. Thanks for working with me, I am glad this was resolved before 5.7.0 was released.
Thanks,
Joe
great! glad that was it. We’ll have this merged in for the 5.7 release. I’ve reported a bug to fix the issue the right way at a later date. Thanks for testing and your patience – these issues can be tedious to say the least!