[GRASSLIST:4347] Re: .gislock woes & success

[Jack Varga]

Hmmm..., come to think of it, when I compiled pre3 I did not
have this problem and I DID use the -mcpu=athlon flag.  For
some reason I opted not to use it this time around because I'm
using 2.4.18-6mdk kernel (Mandrake 8.2) that is compiled for
x86 (even though I have an athlon).  I thought this compile flag
was just for optimization and wouldn't do me any good because
my kernel wasn't compiled specifically for Athlon.  However,
now I'm not so sure.

If anyone is really interested I'd be happy to try recompiling
the pre5 1.1 branch using this flag and see if lock gets built.  

Relatedly, is it possible and how does one pass compiler options
(like -mcpu)  to gmake?

-jv

Bill Sneed wrote:

>
>
> Glynn Clements wrote:
>
>
>> AFAIK, it has also been reported with some versions of gcc-2.96. 
>> However, the problem invariably manifests itself as an "internal
>> compiler error", triggered by some dubious code (a function which is
>> declared as returning "double" but doesn't actually include any
>> "return" statements).
>>
>> Certain code-generation switches cause the problem to disappear, as
>> does changing the function's return type to "void".
>>
>>
>
>
> Thanks for info...
>
> Unfortunately I have no simple way to test 5.0.0pre5 with gcc2.96 
> (don't want to uninstall gcc3.1 !) but I never experienced this 
> problem with previous versions of either GRASS or gcc on this hardware 
> (which is unchanged across multiple versions of GRASS)
>
> If you think the "error" message from trying gmake5 -i etc, etc, would 
> be of help to someone, I'll pass it along....it's beyond my meager 
> abilities to dig through the code....
>
> ...bill sneed, prospect, maine...