Re: Why not use GCC 3.0?
Christopher C. Chimelis wrote:
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.
And couldn't it be possible to make gcc belong to those packages dealt
with "alternatives"?
That way, you could choose easily whatever compiler you want.
For now, you have to remove those links and recreate them pointing to
the gcc version you want.
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.
But ensuring it compiles right away is a must.
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 know personnaly (physically) at least three Alpha owners (including
myself) under Linux (or willing to).
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 :-)
Is Mylex involved?
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 :-)
Could you help me doing this? I'm not sure of the good way to do it.
C
By the way, do you update often your Woody? Samba and others have been
upgraded recently, and I can see a huge difference in the number of
"unaligned trap" I see usinf the binary packages.
Reply to: