[Mesa-dev] VTK Offscreen Segfaults

[Dan Nicholson]

On Fri, Aug 6, 2010 at 2:20 PM, tom fogal <tfogal at sci.utah.edu> wrote:
> "Kevin H. Hobbs" <hobbsk at ohiou.edu> writes:
>> On 08/06/2010 03:15 PM, tom fogal wrote:
>> > If you could build VTK with just a single GL library -- i.e. with
>> > just libOSMesa or just libGL, but not both -- and could reproduce
>> > the crash,= that would rule out my symbol collision theory.  I am
>> > not sure how easy= that is, though...
>>
>> That was shockingly easy... sort of.
>>
>> I did my VTK build with both
>>
>> -DOPENGL_gl_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so
>> -DOSMESA_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so
>>
>> and I left off -fvisibility=3Dhidden thinking that I want the symbols
>> that are now included in libOSMesa.so to be available to VTK.
>
> Nah, the visibility thing only hides symbols that should be hidden
> anyway; i.e. the vbo symbols and the like. gl* will always be available
> regardless of the -fvisibility setting and regardless of which library
> is being built/used.
>
>> and what do you know the test passed.
>
> Great!
>
>> however I wanted to see if VTK is really built with only libOSMesa.so
>> so I did :
>>
>>  $ ldd ../VTK_Build/bin/RenderingCxxTests | grep mesa  libOSMesa.so.7 =>
>>  /tmp/mesa/lib64/libOSMesa.so.7 (0x00007fa97ff4a000)  libGL.so.1 =>
>>  /tmp/mesa/lib64/libGL.so.1 (0x00007fa97bc7a000)
>>
>> so it got pulled in somehow perhaps by libOSMesa.so itself?
>>
>> If I do :
>>
>> $ ldd ../mesa/lib64/libOSMesa.so | grep libGL.so
>>   libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00007f88ed2cf000)
>>
>> because libOSMesa.so needs libGL.so and I have the nvidia drivers in
>> my dynamic linker path but VTK has an rpath set so...
>
> Yeah... hrm, I thought Dan's change got rid of that, but maybe I
> misunderstood it.
>
> Could you rm /tmp/mesa/lib64/libGL.so* before building VTK?  My hunch
> is that VTK is linking it in anyway; maybe it stuck around in cmake's
> cache or something.
>
>> What does all of this mean?
>
> Well, it does appear to be some type of symbol resolution/overloading
> issue.  However it seems to be with internal Mesa symbols.  Switching
> to a single library -- that is, putting OSMesaCreateContext, etc. into
> libGL directly, and getting rid of libOSMesa altogether -- seems like
> it would be the solution, but I imagine there's some reason that's not
> happening already.
>
> Let's ping Dan (added to the CC list), he knows more about this kind
> of thing than I do.  Dan, have you been following this thread?  The
> working theory is that there is a symbol in both libOSMesa and libGL.
> Something about the symbol existing in both is causing Badness during
> linking; seemingly innocuous changes cause Kevin's test program to
> jump into odd parts of Mesa (e.g. VBO code while doing initial matrix
> setup).  The issue appears to be with internal symbols, but hidden
> symbol visibility isn't helping.

Sorry, been busy lately. I haven't been following that closely, but it
doesn't surprise me that there are duplicate symbols in OSMesa and GL.
In fact, we set it up that way so that you could link to OSMesa
without GL, get all the GL entrypoints, and not have to deal with
visibility. So, I _think_ it should be unnecessary to link to GL when
you're using OSMesa because it has all the GL symbols. If that's not
true, we should fix the build so that you do get all the GL symbols
and don't have link with it, too.

So, sorry for not reading the whole thread, but is GL being linked
because it's needed by the app, because pkg-config said so, or because
the linker added it?

--
Dan