Re: DAC960 and GCC
> > There's no gcc in debian that will compile the DAC960 module on my alpha
> > noritake system (as1000a) gcc-3.0 doesn't compile 2.4.17 right, gcc 2.95.4
> > bombs with an error compiling the module, and gcc 2.95.2 (debian potato)
> > just eats all memory and bomb compiling that module.
>
> This is an old problem, but one that was unfortunately never fixed. Can
> you try compiling it without optimisation? IIRC, it still won't compile,
> but it may be worth checking again.
Actually, it did compile when I removed -O2. I haven't tried it yet
What kind of performance hit will happen with -O2 removed?
> > Someone running rh 7.1 and gcc 2.96 was able to compile a kernel for me and
> > it's working great.
>
> DAC960's are strange beasts in some Alphas (only certain firmware revs
> work and they're not easily upgradable since the flash chips are hard to
> find now), so I personally never saw a great need to bump it up on my list
> of things to look into. Plus, I don't have a DAC960 to test with anyway,
> so I couldn't verify anything other than the "it compiles now" type of
> results.
On my alpha, I have firmare 2.70 (I modded the module the other guy compiled
for me so it would work. thankfully it was just a string I changed from
2.73 to 2.00) and it works w/o any problems. 9.89mb/sec read from a raid0
of 3 2gb disks.
A friend of mine on a SMP pc is running the same card (nec branded firmware)
with firmware 2.39 and is getting speeds about 2mb slower than me but he's
using a raid 5 on 4 4gb disks
> > Why is there no gcc 2.96 for alpha (or for that matter, no other arch than
> > ia64)
>
> Because it's an abomination unto the GNU. Just kidding. RedHat
> "fathered" 2.96; it was never an official GNU release. In the beginning
> of 2.96, it had some major problems with it and it would've been
> impossible to turn to the main GCC folks to fix those problems since they
> didn't sanction the release (and they had made enough changes to the CVS
> tree since RH found a snapshot that they could call "2.96" that they
> couldn't easily backport many of the changes). So, that means that, if we
> needed to file bugs, we'd have to rely on RedHat as our "support". I
> don't know about you, but I wouldn't consider having Debian rely on RedHat
> support for something as important as the toolchain :-P
>
> In the IA-64 case, though, it's a little different. Until 3.1 comes out,
> I don't think IA-64 support in even the 3.x series is fantastic. Most of
> the work that is being done is being done in either gcc mainline CVS
> (which we don't want to package for main Debian use for a number of
> reasons) or against the 2.96 sources that were released by RedHat and
> affiliates. I wasn't in on the decision-making process with IA-64, but I
> can agree with their choice as far as that goes even in hindsight. The
> platform is new enough that a working toolchain is needed...doesn't matter
> where it comes from yet. Once the GCC make an official release that works
> well on IA-64, I have no doubts that they'll be switching over to an
> official release for their default compiler.
what about gcc 3.0? It doesn't work well on my alpha, but is it not
recommended?
--
Lab tests show that use of micro$oft causes cancer in lab animals
Reply to: