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

[Glynn Clements]

Jack Varga wrote:

> Hmmm..., come to think of it, when I compiled pre3 I did not
> have this problem and I DID use the -mcpu=athlon flag.

The problem wasn't present in pre3. It was introduced between pre4 and
pre5, and has since been fixed.

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

The compile fails due to an "internal compiler error". This normally
indicates that the compiler has reached a situation which wasn't
expected to occur.

Code generation switches may significantly affect the way in which the
compiler behaves[1], so it isn't particularly surprising that -mcpu=
causes the error to disappear.

[1] E.g. certain warnings are only issued on higher optimisation
levels, as they involve cases whose detection requires information
which is only collected when optimising.

AFAIK, the code in question isn't strictly invalid, just that the
return value is undefined. As nothing actually uses the return value
(the function should have been declared as returning "void", as is now
the case), this shouldn't matter.

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

I don't think that it's possible to pass compiler options when running
gmake5. However, you can set options when running configure, by
setting various environment variables (e.g. CFLAGS, LDFLAGS), as in:

	CFLAGS='-O2 -g -mcpu=athlon' ./configure ...

-- 
Glynn Clements <glynn.clements at virgin.net>