Any news on ATI fglrx 8.42?

[Snake]

Those patches have been around since about 2.6.23-rc1, that was about 10 or 12 weeks ago.
It really shouldn't be a problem to include those patches in 8.42, even in the normal QA cycle.

But as I stated before, compiling for kernel 2.6.23 will work (with a patch) and is nothing to worry about. What might not work is xorg-server 1.4 and about this the community can't do anything and depends on the AMD developers.

Actually I don't know how much the driver depends on the kernel, but because there have been some major changes in arch/ it might break with the next kernel release as well (and that might not be correctable by a patch).

Well, I did not know the patches were around that long. I did not yet update to kernel 2.6.23 nor xserver 1.4, for the very reason that I first want to know for sure what works with 8.42

Personally I'm also concerned of the nasty libstdc++ bug on 64bit (see this thread), that can not be "patched away", too.

But sadly we can not discuss and patch a driver that's not yet released

[rmh3093]

Those patches have been around since about 2.6.23-rc1, that was about 10 or 12 weeks ago.
It really shouldn't be a problem to include those patches in 8.42, even in the normal QA cycle.

But as I stated before, compiling for kernel 2.6.23 will work (with a patch) and is nothing to worry about. What might not work is xorg-server 1.4 and about this the community can't do anything and depends on the AMD developers.

Actually I don't know how much the driver depends on the kernel, but because there have been some major changes in arch/ it might break with the next kernel release as well (and that might not be correctable by a patch).

I agree, not to mention they should be building/testing against the -mm branch since their QA cycle is so long.

[givemesugarr]

Personally I'm also concerned of the nasty libstdc++ bug on 64bit (see this thread), that can not be "patched away", too.

oh, yeah.... that's was the reason i'm still with 8.40.4... now i remember how many times i've broken the second christian precept for this bug during last month.

[d2kx]

NGOHQ I imagine is the same site you're talking about?

Yes.

But sadly we can not discuss and patch a driver that's not yet released

Yeah right. I don't have big issues with fglrx, but I can't understand why they can't just integrate new Kernel and Xorg support earlier. Some skilled people create patches in one day, and they need 2 months to implement them, because of their "safe and stable release plan". Yeah, it is stable and safe, ... that you can't use that driver with uptodate software.

[Kano]

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

[Snake]

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

Interesting But for Java it's not that much of a problem, unless some C++ code that uses libstc++ itself would be linked against the respective Java-Lib...

[npmccallum]

AMD doesn't release on Saturdays and don't expect them to start doing so now. You can go back to past threads and Phoronix articles to see the most popular days.

Taking the release dates from http://en.wikipedia.org/wiki/Fglrx shows the following:
7 Wed
3 Thu
3 Mon
1 Tues
1 Sat
1 Fri

Assuming the release dates are correct:
1. They have in fact released on a Saturday
2. Wednesday is by far the most frequent release date
3. Second most freqent release day is Monday or Thursday
4. Average length between releases is 32 days

Given that Michael has told us the release is this week and that we should look at past release days, it is pretty safe to say the release will be Wednesday. Following that, Thursday. Tuesday (today), Friday and Saturday are extremely unlikely.

[toxigenicpoem]

Well, I did not know the patches were around that long. I did not yet update to kernel 2.6.23 nor xserver 1.4, for the very reason that I first want to know for sure what works with 8.42

Personally I'm also concerned of the nasty libstdc++ bug on 64bit (see this thread), that can not be "patched away", too.

But sadly we can not discuss and patch a driver that's not yet released

This has also affected me with a 32bit install on Debian Etch. Etch has libstdc++ 6 installed by default, apparently the driver is looking specifically for libstdc++ 5.

[Svartalf]

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?

[Raknor]

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