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