Standalone OSMesa

From Gerris

(Difference between revisions)
Jump to: navigation, search
Revision as of 04:59, 15 July 2010
Popinet (Talk | contribs)

← Previous diff
Revision as of 05:05, 15 July 2010
Popinet (Talk | contribs)

Next diff →
Line 25: Line 25:
<li> install locally with the correct options (i.e. [ standalone OSMesa]) <li> install locally with the correct options (i.e. [ standalone OSMesa])
<pre> <pre>
-./configure --prefix=/data01/popinet/local --with-driver=osmesa --with-osmesa-bits=32+./configure --prefix=/home/popinet/local --with-driver=osmesa --with-osmesa-bits=32
make make
make install make install
Line 32: Line 32:
<li> create symlink <li> create symlink
<pre> <pre>
-cd /data01/popinet/local/lib/+cd /home/popinet/local/lib/
ln -s ln -s
</pre> </pre>
Line 38: Line 38:
<li> modify LD_LIBRARY_PATH <li> modify LD_LIBRARY_PATH
<pre> <pre>
-export LD_LIBRARY_PATH=/data01/popinet/local/lib:$LD_LIBRARY_PATH+export LD_LIBRARY_PATH=/home/popinet/local/lib:$LD_LIBRARY_PATH
</pre> </pre>
</li> </li>
Line 44: Line 44:
<pre> <pre>
ldd /usr/bin/gfsview-batch3D | grep OSMesa ldd /usr/bin/gfsview-batch3D | grep OSMesa
- => /data01/popinet/local/lib/ (0x00007f54a50c6000)+ => /home/popinet/local/lib/ (0x00007f54a50c6000)
</pre> </pre>
</li> </li>
</ol> </ol>

Revision as of 05:05, 15 July 2010

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=/home/popinet/local --with-driver=osmesa --with-osmesa-bits=32
    make install
  3. create symlink
    cd /home/popinet/local/lib/
    ln -s
  4. modify LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=/home/popinet/local/lib:$LD_LIBRARY_PATH
  5. check that the linker links with the right library:
    ldd /usr/bin/gfsview-batch3D | grep OSMesa
  => /home/popinet/local/lib/ (0x00007f54a50c6000)

Personal tools