Announcement

Collapse
No announcement yet.

Any news on ATI fglrx 8.42?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael
    replied
    This thread is now being locked. Please continue this discussion in this thread here: http://www.phoronix.com/forums/showthread.php?t=5947 or create a new thread.

    Leave a comment:


  • sishgupta
    replied
    Non akamaied link:
    www2.ati.com/drivers/linux/ati-driver-installer-8.42.3-x86.x86_64.run

    Leave a comment:


  • c0un7d0wn
    replied
    Originally posted by amwriter View Post
    Is this for real...?
    Downloading right now...

    Leave a comment:


  • amwriter
    replied
    Originally posted by Raknor View Post
    Stupid moderation queue. 8.42.3 is here, remove the spaces from the URL below:

    h t t p s : / / a 2 4 8 . e . a k a m a i . n e t / f / 6 7 4 / 9 2 0 6 / 0 / w w w 2 . a t i . c o m / d r i v e r s / l i n u x / a t i - d r i v e r - i n s t a l l e r - 8 . 4 2 . 3 - x 8 6 . x 8 6 _ 6 4 . r u n
    Is this for real...?

    Leave a comment:


  • toxigenicpoem
    replied
    Originally posted by Raknor View Post
    WOOOHOOOOOOOOOOO.... Wait now I have a half of day of work to suffer through. LOL! Can't wait to get home and try this sucker out!

    Leave a comment:


  • Snake
    replied
    Originally posted by Svartalf View Post
    Heh... That's because they're doing C++ driver work and they're trying to target the widest range without knowing some of the latest best practices that people are coming up with from companies like LGP and projects like Autopackage (yes...). <-- snip -->
    I do not indent to repeat that "libstdc++"-thread here, but...

    1) These are the problems that can make using "binary only" software on Linux ...umm... interesting (that's why I rolled eyes when learning that current Java does the same ;-)

    2) I do not think the libstdc++-5 dependency itself is the real problem (libstc++ / gcc 3.3 compat packages should be available nearly everywhere, and just work), but more likely incorrectly overloaded inherited methods on string / char classes inside of AMDs libGL implementation. But without source...

    So. And now I really refuse to further discuss anything technical until I got my hands on 8.42

    Leave a comment:


  • Raknor
    replied
    Stupid moderation queue. 8.42.3 is here, remove the spaces from the URL below:

    h t t p s : / / a 2 4 8 . e . a k a m a i . n e t / f / 6 7 4 / 9 2 0 6 / 0 / w w w 2 . a t i . c o m / d r i v e r s / l i n u x / a t i - d r i v e r - i n s t a l l e r - 8 . 4 2 . 3 - x 8 6 . x 8 6 _ 6 4 . r u n

    Leave a comment:


  • Draco-LVNH
    replied
    hey guys, i have the feeling it will be out in a few hours, i do not know why but i have that feeling maybe because i will be out all day, i always have this luck...

    Leave a comment:


  • Raknor
    replied
    8.42.3 has arrived: https://a248.e.akamai.net/f/674/9206...x86.x86_64.run

    Leave a comment:


  • Svartalf
    replied
    Originally posted by Kano View Post
    I guess the gcc-3.3/libstdc++5 depend must come from an "old" build environment. With debian I can easyly install it, but you are right, it is not really clear why it is still used. Btw. java has the same depend...
    Heh... That's because they're doing C++ driver work and they're trying to target the widest range without knowing some of the latest best practices that people are coming up with from companies like LGP and projects like Autopackage (yes...).

    In this day and age, you'd use a chrooted space pulled from Debian or use Scratchbox with the native binary toolchain and a custom rootstrap (which is an improvement on that thinking...)- or use some contorted build image that's hand-crafted as a cross compiler chain that accomplishes the same result. Now, if you add autobuild from the Autopackage project, you can target distributions with C code that can span from glibc 2.2 forward. For reference, that's before RH 7.2 and Debian Woody.
    From there, you can choose to use librelay from the Autopackage to make things soft dependencies, or not. If you're a C++ application, you're going to probably want to STATICALLY link the libstdc++ in question and provide a dynamic link version for compliance with the licensing requirements of the C++ runtimes with the understanding that there MIGHT be a problem with earlier distributions using that version as there've been three different ABI's on the C++ side of things from the glibc 2.2 timeframe forward and it's a damned minefield otherwise.

    But then, what do I know, right?
    Last edited by Svartalf; 10-23-2007, 12:49 PM.

    Leave a comment:

Working...
X