On 08/06/2010 05:20 PM, tom fogal wrote: > 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.
I just did what might be an interesting experiment. I built mesa from HEAD with : ./autogen.sh --with-driver=xlib --disable-gallium --without-demos --enable-debug I set VTK_USE_X:BOOL=OFF OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.so OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so in cmake and I still get the segfault but now I don't NEED libGL.so so when I replace libGL.so with libOSMesa.so : VTK_USE_X:BOOL=OFF OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so There is no more segfault and the test passes.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
