[vtkusers] OSMESA causes some segfaults

[Kevin H. Hobbs]

On 01/09/2010 08:49 AM, David Doria wrote:
> Wow, what a response, thanks! haha
>
> My answers are inline below:
>
>   
>>  What operating system are you using?
>>     
> Fedora 11
>   

Good, I use Fedora 11 on all of the hooperlab dashboard machines.

>   
>>  Where does your GL library come from, a package or did you build it
>> with Mesa?
>>     
> The package that ships with F11.
>   

As far as I can tell you cannot use this GL with OSMesa and VTK.

>   
>>  Where does your OSMesa library come from, a package or did you build
>> it with Mesa?
>>     
> The package that ships with F11.
>   

I've never been able to get this to work.

>   
>>  Are you sure you are linking against the correct GL library?
>>     
> No.
>
>   

The ldd commands below will answer this.

>>  What does 'grep OSMESA_LIBRARY CMakeCache.txt' in your VTK build
>> directory say?
>>     
> [doriad at davedesktop VTK]$ grep OSMESA_LIBRARY CMakeCache.txt
> MANGLED_OSMESA_LIBRARY:FILEPATH=/usr/lib/libOSMesa.so
> OSMESA_LIBRARY:FILEPATH=/usr/lib/libOSMesa.so
> //ADVANCED property for variable: MANGLED_OSMESA_LIBRARY
> MANGLED_OSMESA_LIBRARY-ADVANCED:INTERNAL=1
> //ADVANCED property for variable: OSMESA_LIBRARY
> OSMESA_LIBRARY-ADVANCED:INTERNAL=1
>
>
>   


Do not use the Mangled Mesa options in the VTK configuration.

Mangled Mesa has not been supported by Mesa for a long time.

You did not use name mangling when you built Mesa ( you did not build
mesa ).


>>  What does 'grep OPENGL_gl_LIBRARY CMakeCache.txt' in your VTK build
>> directory say?
>>     
> [doriad at davedesktop VTK]$ grep OPENGL_gl_LIBRARY CMakeCache.txt
> OPENGL_gl_LIBRARY:FILEPATH=/usr/lib/libGL.so
> //ADVANCED property for variable: OPENGL_gl_LIBRARY
> OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1
>
>   

/usr/lib/libGL.so is the one that comes with Fedora 11. It has been built with DRI support as far as I can tell it does not work with OSMesa. In fact if you look at the source RPM spec file libGL.so and libOSMesa.so were built in separate passes...

 
>>  What does 'ldd DisplayCube | grep GL' say?
>>     
> [doriad at davedesktop Cube]$ ldd DisplayCube | grep GL
> 	libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0x043be000)
> 	libGLcore.so.1 => /usr/lib/nvidia/libGLcore.so.1 (0x01b61000)
>
>   


When run, your program is using the Nvidia drivers instead of the system
ones from the Mesa package these libraries are really not compatable
with OSMesa.


>>  What does 'ldd DisplayCube | grep OSMesa' say?
>>     
> [doriad at davedesktop Cube]$ ldd DisplayCube | grep OSMesa
> 	libOSMesa.so.6 => /usr/lib/libOSMesa.so.6 (0x00ed1000)
>
>   


Your program is linking against the system OSMesa.


>>  Did you build VTK with rpath set?
>>     
> I don't know what you mean?
>
>   

The CMake variable VTK_USE_RPATH controlls whether the paths to other
libraries are written directly into the VTK libraries. If they are then
the run time linker does not have to search for those other libraries it
just uses the one in the rpath. Setting VTK_USE_RPATH to ON disables the
install target in the makefile.

>>  Does your LD_LIBRARY_PATH shell variable direct the linker to find the
>> right GL and OSMesa libraries?
>>     
> As far as I know I only have one version of each (the built in packages).
>
>   

You already have two different GL versions one from Fedora and one from
Nvidia.

You will need another version of GL and OSMesa built to work together.

> As you may be able to tell, I have not done anything (intentionally)
> non-standard, so I was expecting it to "just work". If you see
> anything glaringly wrong in my responses I'll try to check it out
> further.

Two to three things actually:

  Don't use any  Mangled options in CMake.
  Don't mix Nvidia GL and OSMesa.
  Just build Mesa from source. Use rpath, LD_LIBRARY_PATH, or
/etc/ld.so.conf.d/ to get the linker to find it... check it with ldd.

>  Else maybe I'll just wait till the next Fedora release and
> see if it gets fixed.
>
>   

This won't get fixed.

> Thanks again for your help so far,
>   

No problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20100110/d1a909f0/attachment.pgp>