ATI driver 8.41 incompatible with libstdc++.so.5 compat lib

[Snake]

Edit: This bug is fixed as of driver version 8.42.3

Edit: This affects only 64Bit systems!

I filed a bug including a simple testcase at http://ati.cchtml.com/show_bug.cgi?id=812

That could explain some of the segfaults with 8.41 that were already reported on the forums.

If you find time to run the testcase from the bug on your system, you could perhaps post a short "me too" or "works for me" together with your specs here;-)

[Xipeos]

My libGL isn't linked to libstdc++
# ldd /usr/lib/libGL.so
ldd: warning: you do not have execution permission for `/usr/lib/libGL.so'
linux-gate.so.1 => (0xb7f1f000)
librt.so.1 => /lib/librt.so.1 (0xb6fc8000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb6fc4000)
libm.so.6 => /lib/libm.so.6 (0xb6f9d000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6f86000)
libXext.so.6 => /usr/X11/lib/libXext.so.6 (0xb6f77000)
libX11.so.6 => /usr/X11/lib/libX11.so.6 (0xb6e8f000)
libc.so.6 => /lib/libc.so.6 (0xb6d4d000)
/lib/ld-linux.so.2 (0x80000000)
libXau.so.6 => /usr/X11R7.2/lib/libXau.so.6 (0xb6d4a000)
libxcb-xlib.so.0 => /usr/X11/lib/libxcb-xlib.so.0 (0xb6d48000)
libxcb.so.1 => /usr/X11/lib/libxcb.so.1 (0xb6d2e000)
libXdmcp.so.6 => /usr/X11R7.2/lib/libXdmcp.so.6 (0xb6d29000)


fglrx 8.41 on an i686

[DarkFoss]

Mine isn't either.
[larry@Tardis-1 ~]$ ldd /usr/lib/libGL.so
linux-gate.so.1 => (0xbfffe000)
librt.so.1 => /lib/i686/librt.so.1 (0xb70ad000)
libdl.so.2 => /lib/libdl.so.2 (0xb70a9000)
libm.so.6 => /lib/i686/libm.so.6 (0xb7082000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb706e000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb705e000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb6f5b000)
libc.so.6 => /lib/i686/libc.so.6 (0xb6e2c000)
/lib/ld-linux.so.2 (0x80000000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb6e29000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6e23000)

Mandriva 2007.1 x86 fglrx 8.41

[Snake]

Yes, the 32Bit libGL.so does not have a dependency on libstdc++.so.5. So this should not be an issue für 32Bit installs.

But 64Bit has:

spock lib # ldd /usr/lib32/opengl/ati/lib/libGL.so.1.2
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib32/librt.so.1 (0xf7010000)
libdl.so.2 => /lib32/libdl.so.2 (0xf700c000)
libm.so.6 => /lib32/libm.so.6 (0xf6fe5000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf6fce000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf6fbf000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf6ed4000)
libc.so.6 => /lib32/libc.so.6 (0xf6d82000)
/lib/ld-linux.so.2 (0x56555000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf6d7f000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf6d7a000)

spock lib # ldd /usr/lib64/opengl/ati/lib/libGL.so.1.2
libstdc++.so.5 => /usr/lib64/libstdc++-v3/libstdc++.so.5 (0x00002b50053d0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b50056ae000)
librt.so.1 => /lib/librt.so.1 (0x00002b50058c9000)
libdl.so.2 => /lib/libdl.so.2 (0x00002b5005ad3000)
libm.so.6 => /lib/libm.so.6 (0x00002b5005cd7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b5005f58000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00002b5006066000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00002b5006177000)
libc.so.6 => /lib/libc.so.6 (0x00002b500647c000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00002b50067d5000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00002b50068d8000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00002b5006ada000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002b5006cf7000)

[givemesugarr]

am i wrong or the new holy crap was retired from ati website? i was wondering why it hasn't get into portage after 4 days after it was released and i found out that the latest ati driver is the 8.40 one.
may this be caused by this bug?!
and i had also had to install the libstdc++-v3 library (should be a little gcc3.3 library which installs in systems with gcc4 because it compiles only some gcc3 libs) with in the past because it was a dependency for the drivers. i think that amd64 users already should have already installed that library because its lack breakes xwindow with the ati-drivers.

[Raven3x7]

am i wrong or the new holy crap was retired from ati website? i was wondering why it hasn't get into portage after 4 days after it was released and i found out that the latest ati driver is the 8.40 one.
may this be caused by this bug?!
and i had also had to install the libstdc++-v3 library (should be a little gcc3.3 library which installs in systems with gcc4 because it compiles only some gcc3 libs) with in the past because it was a dependency for the drivers. i think that amd64 users already should have already installed that library because its lack breakes xwindow with the ati-drivers.
Its still there www2.ati.com/drivers/linux/linux_8.41.7.html
Im guessing its not in portage because AMD discourages making official packages for it. The distro(Arch) that im using has it in unstable at least for the time beeing.

[Snake]

and i had also had to install the libstdc++-v3 library (should be a little gcc3.3 library which installs in systems with gcc4 because it compiles only some gcc3 libs) with in the past because it was a dependency for the drivers. i think that amd64 users already should have already installed that library because its lack breakes xwindow with the ati-drivers.

libstd++-v3 is installed. The problem is not a missing library, but a segfault (maybe due to different compiler versions or a plain bug in ATI's libGL).

[givemesugarr]

Its still there www2.ati.com/drivers/linux/linux_8.41.7.html
Im guessing its not in portage because AMD discourages making official packages for it.

in portage every version of ati-drivers gets inserted in less than 4 days and it is not packaged, but it is directly installed. gentoo compiles about every single package with some exclusions as openoffice that would take about a day of full compilation with not really much gain in terms of speed, as you can have with the other packages, for example kde. the difference between gentoo and other distros is basically the lack of distro version. once installed it is very easy to mantain and upgrade.
i think that the fact the driver was retired from the one what it is considered the latest (it was released in the last wednesday if i recall right an retired surely on friday when the "latest" driver was the 8.40.4).

libstd++-v3 is installed. The problem is not a missing library, but a segfault (maybe due to different compiler versions or a plain bug in ATI's libGL).

i think that it may be a bug in the ati's libgl. the libstd++-v3 should non be the real cause for this segfault cause it worked quite good with the old drivers. i think that ati has made some modifications in the opengl library of the driver or it is you that is using the new xorg 7.3 which is not compatible with the ati-driver and should break it. for the moment there's no ati user, except for the ones that have a reliable opensource driver, that can use the new xorg. or at least is what i think.

[Snake]

... or it is you that is using the new xorg 7.3 which is not compatible with the ati-driver and should break it. for the moment there's no ati user, except for the ones that have a reliable opensource driver, that can use the new xorg. or at least is what i think.

Nope, using XOrg 7.2 (=xserver 1.3) here.

Did anybody (on a 64Bit system) try the testcase from the bug report (http://ati.cchtml.com/show_bug.cgi?id=812)? Come on, it's pasting the 5 lines of code into a new file testcase.cpp, changing into that directory and executing the two command lines given. Takes 1 minute only, but would give me the confidence that it's no misconfiguration on my system.

The testcase does not even *use* OpenGL (just links to it), so it's not a XOrg version problem or anything esoteric here.

[Alistair]

givemesugar :

I opened the version bump on this driver - ATI cleary posted a caveat on this driver that packagers should not put this drver in distribution as it was not meant for full distribution, but to enable the R600 chips.
This is not to say this driver is ONLY for R600 chips - it simply adds the R600 chips to the drivers 'target' systems.

Further - the Version bump bug on this contains no less than 4 references to issues -- this version will not make it into portage, but the bug and the ebuild it contains are available for your use should you so choose.

The usual 'buyer beware' and ' yer on yer own' warnings of course stand ...

[givemesugarr]

Did anybody (on a 64Bit system) try the testcase from the bug report? Come on, it's pasting the 5 lines of code into a new file testcase.cpp, changing into that directory and executing the two command lines given. Takes 1 minute only, but would give me the confidence that it's no misconfiguration on my system.

on my gentoo amd64 i wasn't able to compile the driver, due to a libgl call stack error. so i couldn't try the testcase with the new driver. what i really know is that this driver would never get into portage due to this compile problem and with amd releasing the 8.42 in about 20 days or so it would not be a great wait until then.

alistair:

you are right and i tried to experience the driver but with no success. guess that when ati said: this is non a driver for mobile and integrated boards and that shouldn't be packaged for distribution knowed very well the problems and bugs they had. i can only ask myself on why they've released the driver when the driver revealed to be a clock bomb. wouldn't have been better to release a simple bugfix driver with only r600 support and then release next month a fully operational 8.42 with aiglx, performance improvements and so on?!

[scott_y]

Hi,
i have the same problem, it will crash a few minutes after starting x. The system just stops.
I am using Gentoo AMD64, with 2900XT.
I get the same seg fault, when i link the test.cpp with GLlib.

[Snake]

Thank's for your attention, everyone.

I get the same seg fault, when i link the test.cpp with GLlib.

So, it is reproducible, and I do not have to close the bug as INVALID ;-)

i have the same problem, it will crash a few minutes after starting x. The system just stops.

Oh, my system does not hang or crash. A 64-Bit app either segfaults early, or works. 32-Bit apps work, Xv works...

All in all just some minor artifacts around the mouse cursor and on the lower right edge of the screen (but both very seldom). And performance has greatly improved here (X1400).

I'm happy to keep the 8.41 "Beta" for now, and look forward to 8.42. The libstdc++ bug means that I can not run 64-Bit OpenGL apps that use libstdc++ string classes for the time being. But the bug itself should be fairly easy to fix in libGL for 8.42, and the report will hopefully help ATI not forgetting to fix it;-)

[Snake]

I did not speak up on that big "Holy crap"-Thread, but since I started this one...

In my opinion, AMD/ATI made a big step towards the communitity, so they also deserve a helpful communitiy now. After all, it will be a win-win for everyone. So, I am grateful that the posts on this thread remained on topic, and did not mutate it into another "let's bash ATI".

It is our linux, and we have to take care to improve it, within our personal skills. A lot of the recent comments in other threads indicate that this general idea is not clear to everyone (perhaps coming from an OS with an other "cultural" background;-)

So, with AMD/ATI being "friendly" now, I will try and take my time to write focused bug reports instead of shouting "crap", "everything crashes" and "by NVIDIA instead". And I see a lot of people that seem to prefer going that "let's improve it" direction, too.

Thank you!

[scott_y]

Oh, my system does not hang or crash. A 64-Bit app either segfaults early, or works. 32-Bit apps work, Xv works...


Is it possible to install/run the 32Bit library instead??
I don´t know why my system freezes after a period of time, there is no log entry.
Do you have any boot options, e.g. vga. I also have to set "noapic".

[lenrek]

It seems to be most of the problem is related with 64Bit. My laptop (is AMD Turion, a 64BIt CPU), runs fine in 32Bit mode.

[chabo]

Gentoo x64: no problems with native 64bit and Cedega 32bit applications. app-emulation/emul-linux-x86-compat has to be installed for 32bit applications on Gentoo.

[Snake]

Is it possible to install/run the 32Bit library instead??No. 64-Bit apps (more exactly: 64-Bit processes) use 64-Bit libs. There are "special" solutions, like nspluginwrapper that allows using 32Bit plugins with 64Bit firefox (well, most of the time;-) But AFAIK there's no way to run a 64Bit X-Server on 32Bit GFX-drivers (would not like to do that, anyway;-)

Do you have any boot options, e.g. vga. I also have to set "noapic".
No. No boot options, and only minimal fglrx driver options (in /etc/X11/xorg.conf and /etc/ati/amdpcsdb). I found that this "settings cruft" that accumulates while tweaking often leads to "strange" behaviour, especially after installing a new driver version.

So, for new driver releases I always start with removing (renaming) /etc/ati/amdpcsdb and the device section in xorg.conf containing only:
Section "Device"
Identifier "ATI Mobility Radeon X1400"
Driver "fglrx"
EndSection

Currently I then just changed these setting (no X-Server must be started while running aticonfig (as root), as I crashes here otherwise):
aticonfig --max-gart-size=256 --overlay-type=Xv --tls=1

I remember that setting thread local storage (TLS) to 2 seemed to help XGL-Server at some time. But if it does not work for you at all (with "clean" settings) I suggest going back to 8.40.4 for the time being. Probably better to wait 2-3 weeks for 8.42 instead of wasting time with 8.41 bugs (that are maybe (perhaps, hopefully) gone with 8.42, anyway;-)

[Snake]

It seems to be most of the problem is related with 64Bit. My laptop (is AMD Turion, a 64BIt CPU), runs fine in 32Bit mode.
Gentoo x64: no problems with native 64bit and Cedega 32bit applications. app-emulation/emul-linux-x86-compat has to be installed for 32bit applications on Gentoo.

Just to be clear: This bug is not about 32Bit apps on 64Bit OS! The reason only 64Bit is affected is that only the 64Bit AMD/ATI libGL.so uses libstdc++.so (the 32Bit libGL does not, so i wonder why it is needed for the 64Bit one at all).

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.