[GRASS5] Problem compiling Grass51

GRASS GRASS developer
21

Hello Radim

On Wed, 30 Apr 2003, Radim Blazek wrote:

On Tuesday 29 April 2003 05:18 pm, Paul Kelly wrote:
> I think we need a G_snprintf() and G_vsnprintf() or something like that.
> Would it be all right just to copy the code straight from a 3rd party
> snprintf implementation to enable this?

I replaced vsnprintf by vfprintf. G_asprintf() seems to be even better
than G_snprintf(). Can I add G_asprintf() suggested by Eric G. Miller
(http://grass.itc.it/pipermail/grass5/2002-May/002936.html) to 5.1?

Nice code is here:
http://www.gnu-darwin.org/sources/4osf1/lib/libc/stdio/asprintf.c
however 'f._file = -1;' is not very portable or yes? I guess
what it means only.

It seems fine on my Irix system and compiles without warnings or errors.
And looks nice and simple as well. I would say go ahead with it.

Paul

22

On Wed, 30 Apr 2003, Radim Blazek wrote:

Are there G_setenv2/G__getenv2 realy available in libgrass_gis.a
(nm libgrass_gis.a)?

No they aren't there, and I can't find any definition for them in the
source code either, just several places where they are called.
Some output below:

doom 1139% nm dist*2/lib/libgrass_gis.a | grep env2
[6] | 8| |Static |struct env* |Data | env2
doom 1140% find . -name '*.[ch]' | xargs grep env2
./lib/db/dbmi/connect.c: G_setenv2("DB_DRIVER", connection->driverName, G_VAR_MAPSET);
./lib/db/dbmi/connect.c: G_setenv2("DB_DATABASE", connection->databaseName, G_VAR_MAPSET);
./lib/db/dbmi/connect.c: connection->driverName = G__getenv2("DB_DRIVER", G_VAR_MAPSET);
./lib/db/dbmi/connect.c: connection->databaseName = G__getenv2("DB_DATABASE", G_VAR_MAPSET);
./lib/gis/env.c:static ENV *env2 = NULL;
./lib/gis/env.c:/* copy env to env2 */
./lib/gis/env.c: env2 = env;
./lib/gis/env.c: if (env2[count].name)
./lib/gis/env.c: set_env (env2[count].name, env2[count].value);
./lib/gis/env.c: env = env2;
./lib/gis/env.c: env2 = tmp;
./lib/vector/Vlib/open.c: frmt = G__getenv2 ( "GV_FORMAT", G_VAR_MAPSET );
./lib/vector/Vlib/field.c: drv = G__getenv2 ( "GV_DRIVER", G_VAR_MAPSET );
./lib/vector/Vlib/field.c: db = G__getenv2 ( "GV_DATABASE", G_VAR_MAPSET );
./lib/vector/Vlib/field.c: G_setenv2 ( "GV_DRIVER", "dbf", G_VAR_MAPSET );
./lib/vector/Vlib/field.c: G_setenv2 ( "GV_DATABASE", "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/", G_VAR_MAPSET );
./lib/vector/Vlib/open_post.c: finfo->post.db = G__getenv2 ( "GV_PGIS_DATABASE", G_VAR_MAPSET );
./include/gisdefs.h:char *G_getenv2(char *, int);
./include/gisdefs.h:char *G__getenv2(char *, int);
./include/gisdefs.h:int G_setenv2(char *, char *, int);
./include/gisdefs.h:int G__setenv2(char *, char *, int);
./include/gisdefs.h:int G_unsetenv2(char *, int);
./vector/v.database/main.c: G_setenv2 ( "GV_DRIVER", driver->answer, G_VAR_MAPSET );
./vector/v.database/main.c: G_setenv2 ( "GV_DATABASE", database->answer, G_VAR_MAPSET );
./vector/v.database/main.c: fprintf(stdout, "driver:%s\n", G__getenv2( "GV_DRIVER", G_VAR_MAPSET) );
./vector/v.database/main.c: fprintf(stdout, "database:%s\n", G__getenv2( "GV_DATABASE", G_VAR_MAPSET) );
doom 1141%

23

On Wed, Apr 30, 2003 at 02:09:08PM +0100, Paul Kelly wrote:

On Wed, 30 Apr 2003, Radim Blazek wrote:

> Are there G_setenv2/G__getenv2 realy available in libgrass_gis.a
> (nm libgrass_gis.a)?

No they aren't there, and I can't find any definition for them in the
source code either, just several places where they are called.
Some output below:

I assume that you are using env.c from 5.0 instead of the 5.1
version.

What does
cvs up lib/gis/env.c

say (conflict?). This file comes from 5.1 as well as a few others in lib/gis/.

Hope this helps,

Markus

24

On Wed, 30 Apr 2003, Markus Neteler wrote:

On Wed, Apr 30, 2003 at 02:09:08PM +0100, Paul Kelly wrote:
> On Wed, 30 Apr 2003, Radim Blazek wrote:
>
> > Are there G_setenv2/G__getenv2 realy available in libgrass_gis.a
> > (nm libgrass_gis.a)?
>
> No they aren't there, and I can't find any definition for them in the
> source code either, just several places where they are called.
> Some output below:

I assume that you are using env.c from 5.0 instead of the 5.1
version.

What does
cvs up lib/gis/env.c

It said to move that file away, it is in the way. So that fixed it! CVS
wouldn't update while it was still linked to GRASS5 (from an old run of
make mix I suppose before there was a GRASS5.1 copy of the file).
So
make mixclean
cvs update -d -P
make mix
seems to have fixed it, thank you. I didn't know about make mixclean
before.

And now for the next error....

make[2]: Entering directory `/indigo-disk2/grass/grass51/lib/gis'
cc -I/indigo-disk2/grass/doom.ee.qub.ac.uk/include -g
-I/indigo-disk2/grass/doom.ee.qub.ac.uk/include
-I/indigo-disk2/grass/grass51/include
-I/indigo-disk2/grass/grass51/dist.mips-sgi-irix6.2/include
-I/indigo-disk2/grass/grass51/include
-I/indigo-disk2/grass/grass51/dist.mips-sgi-irix6.2/include \
        -o OBJ.mips-sgi-irix6.2/debug.o -c debug.c
cfe: Error: debug.c, line 52: 'buffer' undefined; reoccurrences will not
be reported.
        fprintf (fd, "D%d/%d: %s\n", level, grass_debug_level, buffer);
        -------------------------------------------------------^
make[2]: *** [OBJ.mips-sgi-irix6.2/debug.o] Error 1
make[2]: Leaving directory `/indigo-disk2/grass/grass51/lib/gis'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/indigo-disk2/grass/grass51/lib'
make: *** [default] Error 1

25

On Wednesday 30 April 2003 03:41 pm, Paul Kelly wrote:

cfe: Error: debug.c, line 52: 'buffer' undefined; reoccurrences will not
be reported.
        fprintf (fd, "D%d/%d: %s\n", level, grass_debug_level, buffer);

Sorry, hopefully fixed in CVS now

Radim

26

On Wednesday 30 April 2003 03:06 pm, Paul Kelly wrote:

Hello Radim

On Wed, 30 Apr 2003, Radim Blazek wrote:
> On Tuesday 29 April 2003 05:18 pm, Paul Kelly wrote:
> > I think we need a G_snprintf() and G_vsnprintf() or something like
> > that. Would it be all right just to copy the code straight from a 3rd
> > party snprintf implementation to enable this?
>
> I replaced vsnprintf by vfprintf. G_asprintf() seems to be even better
> than G_snprintf(). Can I add G_asprintf() suggested by Eric G. Miller
> (http://grass.itc.it/pipermail/grass5/2002-May/002936.html) to 5.1?
>
> Nice code is here:
> http://www.gnu-darwin.org/sources/4osf1/lib/libc/stdio/asprintf.c
> however 'f._file = -1;' is not very portable or yes? I guess
> what it means only.

It seems fine on my Irix system and compiles without warnings or errors.
And looks nice and simple as well. I would say go ahead with it.

But which one? That by Eric or from gnu-darwin.org?

Radim

27

On Wed, 30 Apr 2003, Radim Blazek wrote:

> It seems fine on my Irix system and compiles without warnings or errors.
> And looks nice and simple as well. I would say go ahead with it.

But which one? That by Eric or from gnu-darwin.org?

Actually I was talking about the gnu-darwin.org one but Eric's compiles OK
as well. I don't really know what they do so can't judge which is better but
maybe Eric can help?

Paul

28

On Wed, 30 Apr 2003, Radim Blazek wrote:

On Wednesday 30 April 2003 03:41 pm, Paul Kelly wrote:
> cfe: Error: debug.c, line 52: 'buffer' undefined; reoccurrences will not
> be reported.
> fprintf (fd, "D%d/%d: %s\n", level, grass_debug_level, buffer);

Sorry, hopefully fixed in CVS now

Radim

Right, here's the next one

make[3]: Entering directory `/indigo-disk2/grass/grass51/db/drivers/dbf'
cc -I/indigo-disk2/grass/doom.ee.qub.ac.uk/include -fullwarn -g
-I/indigo-disk2/grass/doom.ee.qub.ac.uk/include
-I/indigo-disk2/grass/grass51/include
-I/indigo-disk2/grass/grass51/dist.mips-sgi-irix6.2/include
-I/indigo-disk2/grass/grass51/include
-I/indigo-disk2/grass/grass51/dist.mips-sgi-irix6.2/include \
        -o OBJ.mips-sgi-irix6.2/dbfexe.o -c dbfexe.c
cfe: Warning 835: dbfexe.c, line 53: No prototype for the call to yyparse
     if (yyparse() != 0) {
---------------^
To achieve better type-checking, there should be a full prototype for
the function being called.
cfe: Error: dbfexe.c, line 448: This expression is not an lvalue.
            (double) condition = dleval + dreval;
        -----------------------^
cfe: Error: dbfexe.c, line 451: This expression is not an lvalue.
            (double) condition = dleval - dreval;
        -----------------------^
cfe: Error: dbfexe.c, line 454: This expression is not an lvalue.
            (double) condition = dleval * dreval;
        -----------------------^
cfe: Error: dbfexe.c, line 457: This expression is not an lvalue.
            if (dreval != 0.0) (double) condition = dleval / dreval;
        ------------------------------------------^
make[3]: *** [OBJ.mips-sgi-irix6.2/dbfexe.o] Error 1
make[3]: Leaving directory `/indigo-disk2/grass/grass51/db/drivers/dbf'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/indigo-disk2/grass/grass51/db/drivers'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/indigo-disk2/grass/grass51/db'
make: *** [default] Error 1

29

On Wednesday 30 April 2003 05:16 pm, Paul Kelly wrote:

To achieve better type-checking, there should be a full prototype for
the function being called.
cfe: Error: dbfexe.c, line 448: This expression is not an lvalue.
            (double) condition = dleval + dreval;

I don't know much about this code, I have changed 'condition'
to double (in CVS), seems to work, but I am not sure if something else
was not broken. Can you comment this Alex?
Occasionally try to compile again.

Thanks

Radim

30

Paul Kelly wrote:

cfe: Error: dbfexe.c, line 448: This expression is not an lvalue.
            (double) condition = dleval + dreval;

This is a plain bug; a cast is not an lvalue, and so cannot appear as
the LHS of an assignment (a cast can occur *within* the LHS, but not
at the top-level of the LHS).

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

31

Hello Radim

On Wed, 30 Apr 2003, Radim Blazek wrote:

On Tuesday 29 April 2003 05:18 pm, Paul Kelly wrote:
> I think we need a G_snprintf() and G_vsnprintf() or something like that.
> Would it be all right just to copy the code straight from a 3rd party
> snprintf implementation to enable this?

I replaced vsnprintf by vfprintf. G_asprintf() seems to be even better
than G_snprintf(). Can I add G_asprintf() suggested by Eric G. Miller
(http://grass.itc.it/pipermail/grass5/2002-May/002936.html) to 5.1?

I have added Eric's G_asprintf to 5.1 now as I tested it a bit and it
seemed to work best for me. So now it can get a bit more testing. I didn't
realise before but it needs to be used like:

  char *str;
  G_asprintf( &str, "format etc..%s", otherstring);
  /*
    do something
  */
  G_free(str);

I hope it works and is useful

Paul

32

Paul Kelly wrote:

I have added Eric's G_asprintf to 5.1 now as I tested it a bit and it
seemed to work best for me. So now it can get a bit more testing. I didn't
realise before but it needs to be used like:

  char *str;
  G_asprintf( &str, "format etc..%s", otherstring);

Is there any reason why it can't be changed to:

  str = G_asprintf("format etc..%s", otherstring);

?

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

33

On Wed, 21 May 2003, Glynn Clements wrote:

Paul Kelly wrote:

> I have added Eric's G_asprintf to 5.1 now as I tested it a bit and it
> seemed to work best for me. So now it can get a bit more testing. I didn't
> realise before but it needs to be used like:
>
> char *str;
> G_asprintf( &str, "format etc..%s", otherstring);

Is there any reason why it can't be changed to:

  str = G_asprintf("format etc..%s", otherstring);

?

That is maybe better, more like G_store() (whose functionality is quite
similar). Maybe it could be called G_storef() then. Whatever you think. Is
the main reason for changing it that it's confusing the way it is? I had
never seen that way of passing a pointer to a pointer before but it seems
to work?

34

Paul Kelly wrote:

> > I have added Eric's G_asprintf to 5.1 now as I tested it a bit and it
> > seemed to work best for me. So now it can get a bit more testing. I didn't
> > realise before but it needs to be used like:
> >
> > char *str;
> > G_asprintf( &str, "format etc..%s", otherstring);
>
> Is there any reason why it can't be changed to:
>
> str = G_asprintf("format etc..%s", otherstring);
>
> ?

That is maybe better, more like G_store() (whose functionality is quite
similar). Maybe it could be called G_storef() then.

I think that G_asprintf() is the right name.

Whatever you think. Is
the main reason for changing it that it's confusing the way it is?

It just seems more natural. OTOH, the existing prototype matches
asprintf(), so maybe it should be kept.

I had
never seen that way of passing a pointer to a pointer before but it seems
to work?

It will certainly work; the only difference is stylistic.

Maybe that interface was chosen to mimic fprintf, sprintf etc, which
take the "destination" as the first argument. Or maybe it was to force
the caller to store the result somewhere, to prevent memory leaks from
doing this sort of thing:

  foo(..., asprintf(fmt, ...), ...);

Originally I just thought that returning the pointer was neater, but I
can see arguments for the existing interface.

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

35

On Wednesday 21 May 2003 09:32 pm, Glynn Clements wrote:

Paul Kelly wrote:
> > > I have added Eric's G_asprintf to 5.1 now as I tested it a bit and it
> > > seemed to work best for me. So now it can get a bit more testing. I
> > > didn't realise before but it needs to be used like:
> > >
> > > char *str;
> > > G_asprintf( &str, "format etc..%s", otherstring);
> >
> > Is there any reason why it can't be changed to:
> >
> > str = G_asprintf("format etc..%s", otherstring);
> >
> > ?
>
> That is maybe better, more like G_store() (whose functionality is quite
> similar). Maybe it could be called G_storef() then.

I think that G_asprintf() is the right name.

> Whatever you think. Is
> the main reason for changing it that it's confusing the way it is?

It just seems more natural. OTOH, the existing prototype matches
asprintf(), so maybe it should be kept.

I think that it should be either called G_asprintf() and be compatible
with asprintf(), i.e. int G_asprintf(char **strp, const char *fmt, ...)
or it could have different prototype, but different name should be used then.

To keep G_asprintf() matching asprintf() seems to be better.

Paul, do you intend to replace all snprintf() occurrences or should I do that?

Radim