Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Snake
    replied
    Originally posted by lenrek View Post
    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.
    Originally posted by chabo View Post
    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.
    Last edited by Snake; 18 September 2007, 03:45 AM.

    Leave a comment:


  • Snake
    replied
    Originally posted by scott_y View Post
    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;-)

    Originally posted by scott_y View Post
    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:
    Code:
    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):
    Code:
    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;-)

    Leave a comment:


  • chabo
    replied
    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.

    Leave a comment:


  • lenrek
    replied
    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.

    Leave a comment:


  • scott_y
    replied
    Originally posted by Snake View Post
    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".

    Leave a comment:


  • Snake
    replied
    ... and thank you for being constructive!

    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!

    Leave a comment:


  • Snake
    replied
    Thanks for testing ;-)

    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;-)

    Leave a comment:


  • scott_y
    replied
    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.

    Leave a comment:


  • givemesugarr
    replied
    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?!

    Leave a comment:


  • Alistair
    replied
    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 ...

    Leave a comment:

Working...
X