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? 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 ...