What do you mean by removing -O2? I am trying to compile a DAC960 on a Alpha and I am running into this same problem.
TIA, AJ Schroeder -----Original Message----- From: Wakko Warner [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2002 3:17 PM To: Christopher C. Chimelis Cc: [email protected] Subject: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
