Re: Why not use GCC 3.0?
On Tue, 5 Mar 2002, Jerome Warnier wrote:
> Not yet, but I will. I have although to check if such bug reports are
> not already filed.
:-) I definitely know the feeling...
> I understand. But isn't it possible to make certain packages compile
> anyway with gcc-3.0 (for the binary package), without making changes to
> the to-be-frozen-but-freezing-going-really-slow Woody?
Yes and no. I've been cracked on here and there for doing this (or
encouraging this). Also, the C++ ABI is incompatible between 2.95.x and
3.0.x, so you may end up with a "one library is compiled with 3.0 and a
library that depends upon that one is compiled with 2.95" situation, which
will not work. There are sane reasons to why mixing compiler versions is
not a good idea.
> DAC960, I also read the posts on this mailing-list about the firmware
> version (I had the problem, but updated it to 2.73).
> The problem is that I imagine I'm not the only one who needed to add a
> scsi disk in the machine on the NCR controller to boot, compile a newer
> kernel and retry.
True. Then again, I can count the number of folks who've asked about the
DAC960 driver on one hand. Even if we had a default gcc that compiled the
driver properly, it still doesn't guarantee that said driver would be
included in the base install disks.
> If I ever happen to install it back or install another machine like
> that, I would really love to make it as easily as on other platforms. As
> such, I feel I have to report the problems I encountered and try help to
> solve them.
Believe me, I'm glad that you're reporting the problems. Unfortunately,
Alphas have never been a "tons of people use the arch" type of platform,
mostly due to entry price and a variety of other reasons. As such, it
often doesn't get as much testing as I or others would like. So, we rely
on the users to help as much as they can, whether it be by just reporting
bugs (which is incredibly helpful since I can't test everything myself,
nor does my normal usage stress most of the packages that I do use) or
delving into the source and providing a patch.
> I was not able to find out what was the problem until I used my own-made
> 2.4 kernel, because the only message told back by the 2.2.19 kernel
> before the kernel panic was a debug message (a lot of numbers, but
> nothing really usefull to understand what the problem is). I discovered
> afterwards that the Mylex firmware was to old to his liking.
The DAC960 driver is cryptic at best and, as far as alpha goes, very
undocumented. If there is a DAC960 FAQ/HOWTO, it should probably be
updated with Alpha info. Since I don't have one of those boards, though,
I probably shouldn't be the one to do the work :-)
> I personnaly prefer changing gcc version than modify any of the
> parameters of the beautifully hand-made Debian (source) packages ;-)
> It is more convenient, and I prefer to rely on gcc developpers than on
> my own suppositions.
>
> Did you read the bug? It is a very surprising problem of size
> multiplication and data loss.
Yep. I disagree with the maintainer's reasons for degrading the bug to
"important", but it is his package and I suppose his reasons must
stand. If you feel more strongly about it, feel free to take it up with
him. It's probable that a change in the source code would fix this also,
so don't let him get away with "it's a compiler bug", since it may be
weak/weird code that tickles the compiler bug :-)
C
Reply to: