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
