"Kevin H. Hobbs" <hob...@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. -tom _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
