Originally posted by lenrek
View Post
Originally posted by chabo
View Post
The libstc++.so.5 (from the libstdc++-v3 package on gentoo) provides backward compatibility to enable binaries compiled with GCC < 3.4 to be run on GCC >= 3.4 compiled systems (there was a incompatible change between GCC 3.3 and 3.4. Google know more about this;-). It has nothing to do with 64Bit/32Bit compatibility. We're talking about a straight 64Bit enviroment here.
The 64Bit ATI libGL.so seems to be compiled against the "old" (pre GCC 3.4) version, so it has to use the libstdc++-v3 compatibility package. And it seems to use it in a way that leads to the segfault mentioned in the bug report. The libstc++-v3 itself works fine, I've not had problems with it yet.
So the problem is with 8.41 64Bit libGL.so and 64Bit apps that are compiled with GCC > 3.3 and use libGL.so and use libstdc++ string classes themself. But that case is quite common.
32Bit binaries (like UT2004, Penumbra demo, Google earth etc.) do run fine here, because they use the 32Bit libGL.so, and that does not link libstdc++ at all.
The 64Bit apps that I tested so far that do not work are:
- Second Life (self compiled)
- Flightgear (emerged)
- Danger from the deep (emerged)
- Blender (emerge) (seems to run ok, but complains about "char_traits")
The list above is probably much longer, but I did not test each and every "compiled" (= "not 32Bit binary") game in portage yet. And they all segfault with some "std::char_traits" issue, which indicates the 64Bit-libGL.so -> libstdc++.so.5 usage problem.
To set this straight: This bug is not to blame for any problems with 32Bit apps or systems. Strictly 64Bit only here.
As far as I can see 64Bit users will have to bear with some 64Bit OpenGL apps segfaulting until (hopefully) 8.42. Or go back to 8.40 for the time being.
Leave a comment: