Standalone OSMesa

From Gerris

Revision as of 04:59, 15 July 2010; view current revision
←Older revision | Newer revision→
Jump to: navigation, search

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/ [0x7fc13fe3dc00]
[turbine:07885] [ 1] /usr/lib64/ [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/ 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:

  1. get the Mesa tarball
    tar xjvf MesaLib-7.8.2.tar.bz2
  2. install locally with the correct options (i.e. standalone OSMesa)
    ./configure --prefix=/data01/popinet/local --with-driver=osmesa --with-osmesa-bits=32
    make install
  3. create symlink
    cd /data01/popinet/local/lib/
    ln -s
  4. modify LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=/data01/popinet/local/lib:$LD_LIBRARY_PATH
  5. check that the linker links with the right library:
    ldd /usr/bin/gfsview-batch3D | grep OSMesa
  => /data01/popinet/local/lib/ (0x00007f54a50c6000)

Personal tools