[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66955

--- Comment #11 from Phil Armstrong <phil at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130717/6fac0b7b/attachment-0001.html>