https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #11 from Phil Armstrong <p...@kantaka.co.uk> --- <i>Is the libstdc++ that the Xserver sees replaced? If the server is picking up the wrong libstdc++... yeah, don't do that. You wouldn't replace parts of your car engine with random parts from a different model, would you? :)</i> Nope, the Xserver is being linked against the system libstdc++ - it's being launched by gdm3 in a completely stock fashion. The only place the older libstdc++ is being used is when the binary in question is run: the shell script wrapper sets LD_LIBRARY_PATH to point to a directory of support libs, including the old libstdc++. I'm running it from a terminal which in turn is running on the desktop of the original Xsession launched by gdm3. If you look at the error messages from the program, it appears that the r600_dri.so (or any of the other mesa drivers) can't load as a result, because they're trying to link against the old libstdc++ (thanks to the LD_LIBRARY_PATH). I suspect the Xserver crashes because it tries to call into them anyway, despite the fact that the dlopen() call failed. I'll try the INDIRECT thing in the morning, if I get a chance. I doubt the API trace will kill the Xserver, because removing the old libstdc++ from the LD_LIBRARY_PATH of the binary works just fine, although I suppose the binary could be looking at GL features and changing it's behaviour depending on what's available: this is doubtful though as the openGL usage is very basic. It's just texture blits and scaling from watching the program in action. Can't hurt to try of course! -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
