Dear GRASS community,
GRASS 5.0.0 (final) is released.
Find the code at
http://grass.itc.it
(on the mirrors the next days)
There is also a press release:
http://grass.itc.it/announces/press_release500.html
May I say: champagne?!
Cheers
Markus Neteler
[CC to grass5]
Malcolm Blue wrote:
The bad news is that the new math.h in the cygwin distrib has a
declaration for "round" that conflicts with declaration in
d.zoom/cmd/set.c and imagery/i.pca/cmd/main.c. I had to change "round"
to "_round" in these two files to make these routines compile.
Hmm. GNU libc's math.h also declares "round", but only if __USE_ISOC9X
is defined. I wonder if Cygwin's gcc defaults to C9X rather than C89.
IIRC, the most recent versions of gcc (3.x, maybe some later 2.9x)
have an option to select the dialect (C89/C9X), so it may be possible
to get around this problem by setting CFLAGS prior to running
"configure".
In any case:
1. We should probably pick another name for the function in
d.zoom/cmd/set.c. "round(x)" is normally understood as meaning the
same thing as "floor(x+0.5)".
2. We should consider whether configure should attempt to detect the
existence of a round() function, and define HAVE_ROUND accordingly;
imagery/i.pca/cmd/main.c could then conditionalise its local
definition.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn,
Hmm. GNU libc's math.h also declares "round", but only if
__USE_ISOC9X is defined. I wonder if Cygwin's gcc defaults to
C9X rather than C89.
It appears to. Round is declared after:
#ifndef __STRICT_ANSI__
/* ISO C99 types and macros. */
IIRC, the most recent versions of gcc (3.x, maybe some later
2.9x) have an option to select the dialect (C89/C9X), so it
may be possible to get around this problem by setting CFLAGS
prior to running "configure".
You are right, I could have defined __STRICT_ANSI__ to avoid this error.
Thanks,
Malcolm
In any case:
1. We should probably pick another name for the function in
d.zoom/cmd/set.c. "round(x)" is normally understood as
meaning the same thing as "floor(x+0.5)".2. We should consider whether configure should attempt to
detect the existence of a round() function, and define
HAVE_ROUND accordingly; imagery/i.pca/cmd/main.c could then
conditionalise its local definition.--
Glynn Clements <glynn.clements@virgin.net>_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Malcolm Blue wrote:
> Hmm. GNU libc's math.h also declares "round", but only if
> __USE_ISOC9X is defined. I wonder if Cygwin's gcc defaults to
> C9X rather than C89.
>It appears to. Round is declared after:
#ifndef __STRICT_ANSI__
/* ISO C99 types and macros. */
> IIRC, the most recent versions of gcc (3.x, maybe some later
> 2.9x) have an option to select the dialect (C89/C9X), so it
> may be possible to get around this problem by setting CFLAGS
> prior to running "configure".
>You are right, I could have defined __STRICT_ANSI__ to avoid this error.
Or used "gcc -ansi ...", which causes that macro to be defined.
However, I suspect that either approach would be a bad idea; much of
GRASS is not ANSI conformant.
That does at least tell me that the code has to be changed; it can't
be solved through compiler switches.
--
Glynn Clements <glynn.clements@virgin.net>
On Mon, Sep 09, 2002 at 05:11:50PM +0100, Glynn Clements wrote:
Malcolm Blue wrote:
> > Hmm. GNU libc's math.h also declares "round", but only if
> > __USE_ISOC9X is defined. I wonder if Cygwin's gcc defaults to
> > C9X rather than C89.
> >
>
> It appears to. Round is declared after:
>
> #ifndef __STRICT_ANSI__
>
> /* ISO C99 types and macros. */
>
> > IIRC, the most recent versions of gcc (3.x, maybe some later
> > 2.9x) have an option to select the dialect (C89/C9X), so it
> > may be possible to get around this problem by setting CFLAGS
> > prior to running "configure".
> >
>
> You are right, I could have defined __STRICT_ANSI__ to avoid this error.Or used "gcc -ansi ...", which causes that macro to be defined.
However, I suspect that either approach would be a bad idea; much of
GRASS is not ANSI conformant.That does at least tell me that the code has to be changed; it can't
be solved through compiler switches.
If checking for which C standard is in operation, one can check for
__STDC__VERSION__ which should be defined for any C implementation
conforming to iso9899:199409 (i.e. >= C94 amendment):
#if defined __STDC__VERSION__
# if __STDC__VERSION__ + 0 < 199900L
# define round(x) floor((x)+0.5)
# endif
#else
# define round(x) floor((x)+0.5)
#endif
Or something... Not sure when round() was introduced; think C99. Might
also be POSIX or XOPEN preceeding C99...
Borderline functions that may be supported in some environments, but
not others should be handled via config and compatibility routines.
It's probably easier to test for them in ./configure as well...
rint() is probably preferrable to round() which normally should round
to nearest rather than away from zero as round() does. But, it is
C99...
--
begin 664 .signature
M<F5L;&E-("Y'(&-I<D4@/G1E;BYS<&I`,FUG93P)"`@("`@("`@("`@("`@(
M"`@("`@("`@("`@("`@("`A%<FEC($<N($UI;&QE<B`\96=M,D!J<',N;F5T
"/@H`
`
end