RE: DAC960 and GCC
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:wakko@animx.eu.org]
Sent: Friday, January 25, 2002 3:17 PM
To: Christopher C. Chimelis
Cc: debian-alpha@lists.debian.org
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 debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: