[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: