[GRASS-dev] grass7 compilation error

GRASS GRASS developer
,
1

Hi,

there is new problem with compiling grass7 on Windows

landa@GEO1 /osgeo4w/usr/src/grass_trunk/raster3d/r3.in.v5d
$ make
gcc -I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-D_FILE_OFFSET_BITS=64 -DLITTLE -DPACKAGE=\""grassmods"\"
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include -o
OBJ.i686-pc-mingw32/v5d.o -c v5d.c
v5d.c: In function `v5dCreateFile':
v5d.c:2342: error: `mode_t' undeclared (first use in this function)
v5d.c:2342: error: (Each undeclared identifier is reported only once
v5d.c:2342: error: for each function it appears in.)
v5d.c:2342: error: syntax error before "mask"
v5d.c:2345: error: `mask' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/v5d.o] Error 1

Could be related to LFS issue?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

2

On Mon, Aug 16, 2010 at 9:15 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

there is new problem with compiling grass7 on Windows

landa@GEO1 /osgeo4w/usr/src/grass_trunk/raster3d/r3.in.v5d
$ make
gcc -I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-D_FILE_OFFSET_BITS=64 -DLITTLE -DPACKAGE=\""grassmods"\"
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include -o
OBJ.i686-pc-mingw32/v5d.o -c v5d.c
v5d.c: In function `v5dCreateFile':
v5d.c:2342: error: `mode_t' undeclared (first use in this function)
v5d.c:2342: error: (Each undeclared identifier is reported only once
v5d.c:2342: error: for each function it appears in.)
v5d.c:2342: error: syntax error before "mask"
v5d.c:2345: error: `mask' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/v5d.o] Error 1

Could be related to LFS issue?

I guess unlikely:

man 2 chmod

SYNOPSIS
       #include <sys/stat.h>

       int chmod(const char *path, mode_t mode);
       int fchmod(int fd, mode_t mode);

Can you try adding
#include <sys/stat.h>
?

Markus

3

Hi,

2010/8/16 Markus Neteler <neteler@osgeo.org>:

On Mon, Aug 16, 2010 at 9:15 AM, Martin Landa <landa.martin@gmail.com> wrote:

Could be related to LFS issue?

I guess unlikely:

man 2 chmod

SYNOPSIS
#include <sys/stat.h>

  int chmod\(const char \*path, mode\_t mode\);
  int fchmod\(int fd, mode\_t mode\);

Can you try adding
#include <sys/stat.h>

no, it didn't help.

See http://www.gnu.org/s/libc/manual/html_node/Attribute-Meanings.html
which notes `struct stat`.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

4

Martin Landa wrote:

Hi,

there is new problem with compiling grass7 on Windows

landa@GEO1 /osgeo4w/usr/src/grass_trunk/raster3d/r3.in.v5d
$ make
gcc -I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-D_FILE_OFFSET_BITS=64 -DLITTLE -DPACKAGE=\""grassmods"\"
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include -o
OBJ.i686-pc-mingw32/v5d.o -c v5d.c
v5d.c: In function `v5dCreateFile':
v5d.c:2342: error: `mode_t' undeclared (first use in this function)
v5d.c:2342: error: (Each undeclared identifier is reported only once
v5d.c:2342: error: for each function it appears in.)
v5d.c:2342: error: syntax error before "mask"
v5d.c:2345: error: `mask' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/v5d.o] Error 1

Could be related to LFS issue?

Yes. I'll fix it.

Markus M

5

Markus Metz wrote:

Martin Landa wrote:

Hi,

there is new problem with compiling grass7 on Windows

landa@GEO1 /osgeo4w/usr/src/grass_trunk/raster3d/r3.in.v5d
$ make
gcc -I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-D_FILE_OFFSET_BITS=64 -DLITTLE -DPACKAGE=\""grassmods"\"
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include
-I/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/include -o
OBJ.i686-pc-mingw32/v5d.o -c v5d.c
v5d.c: In function `v5dCreateFile':
v5d.c:2342: error: `mode_t' undeclared (first use in this function)
v5d.c:2342: error: (Each undeclared identifier is reported only once
v5d.c:2342: error: for each function it appears in.)
v5d.c:2342: error: syntax error before "mask"
v5d.c:2345: error: `mask' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/v5d.o] Error 1

Could be related to LFS issue?

Yes. I'll fix it.

fixed in r43137

Markus M

6

Markus Metz wrote:

fixed in r43137

Regarding the comment:

LFS for wingrass: another old name. use typedef instead of define?

In general, you should use typedef's for types. #define should be a
last resort, as it affects all use of the name regardless of context.

Also, what is the reason for defining _NO_OLDNAMES? Is there no
alternative?

--
Glynn Clements <glynn@gclements.plus.com>

7

Glynn Clements wrote:

Markus Metz wrote:

fixed in r43137

Regarding the comment:

LFS for wingrass: another old name. use typedef instead of define?

In general, you should use typedef's for types. #define should be a
last resort, as it affects all use of the name regardless of context.

OK

Also, what is the reason for defining _NO_OLDNAMES? Is there no
alternative?

Looking for one, but I do not get the initial approach with
#define lseek lseek64
to work, see ticket #1131.

Anyway, I will be out of office for some days, let's leave it
deactivated for the time being.

Markus M

8

Markus Metz wrote:

> Also, what is the reason for defining _NO_OLDNAMES? Is there no
> alternative?

Looking for one, but I do not get the initial approach with
#define lseek lseek64
to work, see ticket #1131.

Right.

Try explicitly including <io.h> and/or <stdio.h> before defining the
macros. Both headers are protected against repeated inclusion.

Also, this issue should only affect code which explicitly includes
<grass/config.h> before the system header files, which is a bad idea.
I've fixed lib/gis/copy_dir.c; please fix any others which you may
encounter.

--
Glynn Clements <glynn@gclements.plus.com>

9

Glynn Clements wrote:

Markus Metz wrote:

> Also, what is the reason for defining _NO_OLDNAMES? Is there no
> alternative?

Looking for one, but I do not get the initial approach with
#define lseek lseek64
to work, see ticket #1131.

Right.

Try explicitly including <io.h> and/or <stdio.h> before defining the
macros. Both headers are protected against repeated inclusion.

That would work.

Also, this issue should only affect code which explicitly includes
<grass/config.h> before the system header files, which is a bad idea.

Why so? Including grass/config.h after all relevant systems headers
and before all grass headers contradicts current design which
assumes/requires that grass/config.h is included before some system
headers. In config.h.in, lines 23 to 76, there are, amongst others,
HAVE_SYS_TYPES_H and HAVE_UNISTD_H (unistd.h maps roughly to io.h on
mingw). That implies that grass/config.h is supposed to be included
before these headers (and all headers that pull these in) and that
these headers should only be included if the corresponding macros are
set in grass/config.h. Or is this part of config.h.in a remnant from
old days and is no longer necessary today?

Markus M

10

Markus Metz wrote:

> Also, this issue should only affect code which explicitly includes
> <grass/config.h> before the system header files, which is a bad idea.

Why so? Including grass/config.h after all relevant systems headers
and before all grass headers contradicts current design which
assumes/requires that grass/config.h is included before some system
headers.

In config.h.in, lines 23 to 76, there are, amongst others,
HAVE_SYS_TYPES_H and HAVE_UNISTD_H (unistd.h maps roughly to io.h on
mingw). That implies that grass/config.h is supposed to be included
before these headers (and all headers that pull these in) and that
these headers should only be included if the corresponding macros are
set in grass/config.h. Or is this part of config.h.in a remnant from
old days and is no longer necessary today?

The general sentiment is true; if you need the feature tests, you have
to include <grass/config.h> first. But the entries for <unistd.h> and
<sys/types.h> are pointless; we assume that (unless __MINGW32__ is
defined) you have a system which is at least minimally POSIX
compliant.

In general, you normally include headers in decreasing order of
standard-ness, i.e. ANSI/ISO C headers first, then POSIX headers, then
headers for "core" libraries, then for "add-on" libraries, then the
"common" headers for the package being built, with the headers for the
specific module or subsystem coming last.

Third-party libraries have to accommodate system headers (e.g. not
using variable names which conflict with typedefs in the system
headers), as system headers aren't written to accommodate third-party
libraries.

In that regard, there shouldn't be any reason to include
<grass/config.h> before the most common POSIX headers, and certainly
not before the ANSI/ISO C headers (if you don't have those, GRASS
isn't going to compile).

I'm starting to think that the MinGW-LFS stuff should go at the top of
gis.h, and config.h should be kept conservative (i.e. just defining
ALL_CAPS macros, which are less likely to conflict with anything).

--
Glynn Clements <glynn@gclements.plus.com>