Re: Why not use GCC 3.0?
Christopher C. Chimelis wrote:
On Thu, 7 Mar 2002, Jerome Warnier wrote:
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.
This has been gone over (and over and over and over) in the BTS at least
once per week. There are many reasons why Matthias chose not to use
alternatives for the compilers, but I won't go into those here (they are
valid reasons). If you want to change the default compiler on YOUR
system, though, you're welcome to do so. You can alter the gcc-defaults
package locally and rebuild it to save yourself the effort of having to
delete/relink things all over the place (those links come from packages
built by gcc-defaults).
I understand... though I will look carefully at the reasons invoked not
to do it. The "alternatives" is a very powerful way to do such things
indeed.
Bloating them would not make anything easier.
But ensuring it compiles right away is a must.
Well, that's subjective criteria. I can't (and won't) use the criteria of
"the whole kernel and every driver should compiler perfectly with the
default compiler" before making the determination on which compiler should
be the default on Alpha. If I did, then we would never have a default
compiler since not one of them has been perfect in that regard. Not to
belittle your situation, but I would be MUCH more concerned if the aic78xx
drivers wouldn't compile correctly (due to their widespread usage) than I
am about the DAC960 (which even egcs never compiled properly). Also, keep
in mind that, frequently, small code changes in the drivers or even the
Makefiles can fix some of the problems experienced, but since nobody has
looked into it (purely lack of time) or hasn't had the hardware available
to test the drivers out even if they did compile, such investigations just
haven't been done beyond the cursory "it's broke" glance.
My opinion was that the machine I'm talking about has been sold by
Digital "as-is". The Mylex controller was in there. And all disks are
attached to it. If this machine has no Mylex controller support, it is
unusable...
I wondered why this still happened today, and I suppose a number of
these have been sold, why is nobody else complaining?
I know personnaly (physically) at least three Alpha owners (including
myself) under Linux (or willing to).
I know quite a few more, but most won't ever find the time to test things
like caudium-related stuff or every one of the mail readers that we have
in the distribution, for example. On x86, this is easy since sheer
numbers dictate that at least one person other than the maintainer should
be using each package (statistically, at least), but alpha doesn't enjoy
that volume in the installed-base dept.
Just a question of capitilizing the few users...
I'm ready (and willing) to help, I'm not too bad, I have a strong
experience with various systems... but I'm not programmer.
I could even submit good bug reports, if only I knew how to do it
without frustrating anybody.
This Netatalk thing is a good example. How do I do to report a solution
to an already existing bug #, but forwarded to upstream maintainers?
I even have some solution and am willing to help!
Is Mylex involved?
My last exchange with Mylex was less than satisfying in the information
dept for me. In fact, most of the manufacturers of SCSI controllers have
been less than helpful when it comes to Alpha problems (even when I
spoon-feed them details...don't even ask about my work on the MegaRAID
driver and AMI's attitude). They simply see it as an unsupported (or
largely so) platform and will end up tossing the ball back to us to solve
it while simultaneously providing us with too few details to accomplish
it (and hiding behind NDAs if you want more).
If only they all understood the Open Source spirit!
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.
Well, John Goerzen is a very competent programmer, IMO, so he may be able
to help more with this than I can (plus, he's familiar with and can
reproduce the problem...my Mac is wireless and my WAP11 doesn't forward
AppleTalk packets, unfortunately, making it hard to reproduce for me).
If it was just a question of playing with build arguments, I could do it
myself. But it needs playing with packages, and I'm not ready to do so,
nor do I know where to look...
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.
I keep my SX running unstable always because I have to upload packages for
unstable and need the environment to be at that package-level to test
things. I do plan on deleting my old/hosed woody chroot and setting up a
new one, but just haven't gotten around to it yet. Also, because of the
sheer amount of machines that I have in my house, I rarely get to see the
console, so I don't get to see the unaligned access warnings unless I
specifically look for them.
I read many times that those "unaligned traps" had a huge impact on
performance, don't you notice anything?
C
Reply to: