CFD Online Discussion Forums - [OpenFOAM.org] Error when building Paraview on ARM laptop

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Installation (https://www.cfd-online.com/Forums/openfoam-installation/)

- - [OpenFOAM.org] Error when building Paraview on ARM laptop (https://www.cfd-online.com/Forums/openfoam-installation/216720-error-when-building-paraview-arm-laptop.html)

Error when building Paraview on ARM laptop

Hi, I'm trying to compile ParaView 5.4.0 (as a part of ThirdParty-6) on an armv7 laptop running Parabola linux. However, the build is failing at about 10%. The full build log file is available here:

https://cloud.disroot.org/s/yNH83kRwNWfEE75

I am trying to compile with mpi, qt and mesa support, but not python. The main issue seems to be that I am getting quite a few errors like this:

Code:

/usr/bin/ld: gl_draw.c:(.text+0xd4): undefined reference to `glGetDoublev'

/usr/bin/ld: gl_draw.c:(.text+0xe0): undefined reference to `glGetDoublev'

/usr/bin/ld: gl_draw.c:(.text+0x148): undefined reference to `glClearColor'

/usr/bin/ld: gl_draw.c:(.text+0x170): undefined reference to `glMatrixMode'

/usr/bin/ld: gl_draw.c:(.text+0x178): undefined reference to `glLoadMatrixd'

/usr/bin/ld: gl_draw.c:(.text+0x180): undefined reference to `glMatrixMode'

So, it seems like an OpenGL issue. The laptop doesn't have an operational GPU, so I'm not entirely sure if my mesa/OpenGL settings are correct.

Does anyone have any ideas?

Quick answer:

OSMesa is not the same as Mesa... what I mean is that OSMesa is strictly for off-screen rendering (no GUI) and Mesa is for rendering with the CPU and compatible GPUs.
Since you're trying to build ParaView 5.4.0, you can still try to build with OpenGL and not OpenGL2 that you are trying right now. Add the following option to the makeParaView build string that you are using right now:

Code:

-rendering OpenGL

and it will try to build with the old OpenGL version.
In order to know which libraries you need for building OpenGL applications on Parabola Linux, you should check simpler applications that already have packages on their package manager and check what they depend on. For example, try installing the package "mesa-demos" and see if you can run:

Code:

glxgears

and it should show three rotating gears in 3D. But if it doesn't work, then ParaView will not build either.

Thanks for your reply. I installed mesa-demos and

Code:

glxgears

seems to run fine.

So, are you saying that I should not enable OSMesa? I must admit I am a bit confused as to what 'off-screen rendering' is and what OSMesa does. Why would someone want to render something off-screen, without a GUI?

I will try compiling with OpenGL, rather than OpenGL2, as you suggest. So, would that option be the same as enabling RENDERING_BACKEND=OpenGL in the 'makeParaview' build script?

I tried switching the MESA_LIBRARY setting in the makeParaView script from '/usr/lib/libOSMesa.so' to '/usr/lib/libGLX_mesa.so'. I left OpenGL at version 2. The build got a lot further and I didn't see those same errors. However, it failed at 51%. Here is the build log:

https://cloud.disroot.org/s/2nCy9efMFcyBBZY

This seems to be the key error:

Code:

/usr/bin/ld: CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o: in function `vtkXOpenGLRenderWindow::IsCurrent()':

vtkXOpenGLRenderWindow.cxx:(.text+0x1dc): undefined reference to `OSMesaGetCurrentContext'

/usr/bin/ld: CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o: in function `vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int)':

vtkXOpenGLRenderWindow.cxx:(.text+0x23b4): undefined reference to `OSMesaGetProcAddress'

/usr/bin/ld: vtkXOpenGLRenderWindow.cxx:(.text+0x24a4): undefined reference to `OSMesaCreateContext'

/usr/bin/ld: CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o: in function `vtkXOpenGLRenderWindow::DestroyOffScreenWindow()':

vtkXOpenGLRenderWindow.cxx:(.text+0x2a68): undefined reference to `OSMesaDestroyContext'

/usr/bin/ld: CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o: in function `vtkXOpenGLRenderWindow::MakeCurrent()':

vtkXOpenGLRenderWindow.cxx:(.text+0x418c): undefined reference to `OSMesaMakeCurrent'

So, it seems similar to the previous error, but now it can't find references to OSMesa functions. But why is it still trying to use OSMesa?

I'm a bit confused - with the previous mesa library path, it couldn't find OpenGL functions, but now I changed the library path so it can find those, it now can't find OSMesa functions.

Quote:

Originally Posted by Time4Tea (Post 731118)

So, are you saying that I should not enable OSMesa? I must admit I am a bit confused as to what 'off-screen rendering' is and what OSMesa does. Why would someone want to render something off-screen, without a GUI?

When running on a cluster or supercomputer and you want it to run from a script or control it remotely through ParaView's client-server capabilities.

Quote:

Originally Posted by Time4Tea (Post 731118)

So, would that option be the same as enabling RENDERING_BACKEND=OpenGL in the 'makeParaview' build script?

Yes. A few more details are available here: https://openfoamwiki.net/index.php/I...hics_driver.22

Quote:

Originally Posted by Time4Tea (Post 731161)

I tried switching the MESA_LIBRARY setting in the makeParaView script from '/usr/lib/libOSMesa.so' to '/usr/lib/libGLX_mesa.so'.

No no no... no.. why? Didn't the OpenGL build mode work?

Because the only alternative left is to build Mesa and not OSMesa, which no makeParaView script provides at the moment out of box... read/study the information given here: https://bugs.openfoam.org/view.php?id=2888#c9979

Quote:

Originally Posted by wyldckat (Post 731380)

No no no... no.. why? Didn't the OpenGL build mode work?

Well, OSMesa didn't sound like it was something I needed. Also, when I changed that library path, it seemed to fix the errors I was seeing initially (with it not being able to find opengl references), although it then gave me different errors later on, that it couldn't find osmesa references.

I tried the build with OpenGL (and qt4), but it failed in a similar way to my first attempt:

Code:

[  7%] Building C object VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5.dir/H5Dchunk.c.o

[  7%] Linking C shared library ../../../../../lib/libIceTGL.so

/usr/bin/ld: CMakeFiles/IceTGL.dir/gl_state.c.o: in function `gl_destroy':

gl_state.c:(.text+0x68): undefined reference to `glDeleteTextures'

/usr/bin/ld: CMakeFiles/IceTGL.dir/gl_draw.c.o: in function `icetGLDrawFrame':

gl_draw.c:(.text+0xa8): undefined reference to `glGetIntegerv'

/usr/bin/ld: gl_draw.c:(.text+0xc4): undefined reference to `glGetFloatv'

/usr/bin/ld: gl_draw.c:(.text+0xd4): undefined reference to `glGetDoublev'

/usr/bin/ld: gl_draw.c:(.text+0xe0): undefined reference to `glGetDoublev'

 /usr/bin/ld: gl_draw.c:(.text+0x148): undefined reference to `glClearColor'

So, I tried disabling mesa entirely. At first, I used OpenGL2 & qt5, which got almost to the end, but failed at around 85% with the following type of error:

Code:

[ 84%] Building CXX object Wrapping/ClientServer/CMakeFiles/vtkPVVTKExtensionsDefaultCS.dir/vtkRulerLineForInputClientServer.cxx.o

[ 84%] Building CXX object Wrapping/ClientServer/CMakeFiles/vtkPVClientServerCoreRenderingCS.dir/vtkPVImplicitCylinderRepresentationClientServer.cxx.o

/usr/bin/ld: ../../../lib/libvtkPVServerImplementationRendering-pv5.4.so.1: invalid string offset 10986 >= 9150 for section `.strtab'

/usr/bin/ld: ../../../lib/libvtkPVServerImplementationRendering-pv5.4.so.1: invalid string offset 10974 >= 9150 for section `.strtab'

/usr/bin/ld: ../../../lib/libvtkPVServerImplementationRendering-pv5.4.so.1: invalid string offset 10960 >= 9150 for section `.strtab'

/usr/bin/ld: ../../../lib/libvtkPVServerImplementationRendering-pv5.4.so.1: invalid string offset 10941 >= 9150 for section `.strtab'

So, I tried it with no mesa, OpenGL and qt4, and that did fully build. I will proceed with that for now and see how it works.

With mesa enabled, it seemed like I had to choose between pointing that library path to either GLX or OSMesa; however, the build process seemed to expect both.