On some systems OSMesa crashes when it tries to use the system's OpenGL library. The symptom of this is trying to use gfsview-batch or GfsOutputView and getting a segmentation fault looking like:
[turbine:07885] *** Process received signal *** [turbine:07885] Signal: Segmentation fault (11) [turbine:07885] Signal code: Address not mapped (1) [turbine:07885] Failing at address: 0x6b0 [turbine:07885] [ 0] /lib64/libpthread.so.0 [0x7fc13fe3dc00] [turbine:07885] [ 1] /usr/lib64/libGL.so.1(glDisable+0x7) [0x7fc140812447] [turbine:07885] *** End of error message *** Segmentation fault (core dumped)
OSMesa is designed to be a standalone OpenGL implementation so should not really need to link with the system's OpenGL library (/usr/lib64/libGL.so.1 in the example above). The problem is that packagers of Mesa/OSMesa on most systems (at least Debian/Ubuntu derivatives and Suse derivatives) do not seem to be aware of this and package OSMesa so that it relies on an external OpenGL library (which can be Mesa itself or any other implementation which can be graphics-hardware-dependent).
Other than asking the package maintainers to fix their packaging, the solution is to recompile OSMesa locally and make sure that the dynamic linker uses this local version as opposed to the default system OSMesa library.
This can be done by:
- get the Mesa tarball
wget ftp://ftp.freedesktop.org/pub/mesa/7.8.2/MesaLib-7.8.2.tar.bz2 tar xjvf MesaLib-7.8.2.tar.bz2
- install locally with the correct options (i.e. standalone OSMesa)
./configure --prefix=/data01/popinet/local --with-driver=osmesa --with-osmesa-bits=32 make make install
- create symlink
cd /data01/popinet/local/lib/ ln -s libOSMesa32.so.7 libOSMesa.so.7
- modify LD_LIBRARY_PATH
- check that the linker links with the right library:
ldd /usr/bin/gfsview-batch3D | grep OSMesa libOSMesa.so.7 => /data01/popinet/local/lib/libOSMesa.so.7 (0x00007f54a50c6000)