[GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk

martinl · August 26, 2009, 12:44pm

2009/8/26 <svn_grass@osgeo.org>:

Author: glynn
Date: 2009-08-26 08:41:06 -0400 (Wed, 26 Aug 2009)
New Revision: 38872

Modified:
grass/trunk/configure
grass/trunk/configure.in
Log:
Revert r38867 (bogus GEOM check)

can you explain why it's bogus. Now configuration fails with

checking for geos-config... /usr/local/bin/geos-config
checking for geos_c.h... yes
checking for GEOSGeom_createLinearRing in -lgeos... no
configure: error: *** Unable to locate GEOS library.

initGEOS or GEOSGeom_createLinearRing are defined in GEOS C API (geos_c)...

Martin

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

Glynn_Clements1 · August 26, 2009, 8:33pm

Martin Landa wrote:

> Author: glynn
> Date: 2009-08-26 08:41:06 -0400 (Wed, 26 Aug 2009)
> New Revision: 38872
>
> Modified:
> grass/trunk/configure
> grass/trunk/configure.in
> Log:
> Revert r38867 (bogus GEOM check)

can you explain why it's bogus. Now configuration fails with

checking for geos-config... /usr/local/bin/geos-config
checking for geos_c.h... yes
checking for GEOSGeom_createLinearRing in -lgeos... no
configure: error: *** Unable to locate GEOS library.

It's bogus insofar as the check succeeds but GRASS fails to compile
due to GEOS-related errors. Checks are, well, checks; they're supposed
to fail if everything isn't in order.

[However I have just discovered that the problems aren't related to
the libraries, only the headers. IOW, the check wasn't specifically
wrong, just insufficient; but it turns out to be easier to make GEOS
2.x work than to detect and avoid it.]

Although, my errors weren't those in Markus' original post; instead:

  make[4]: Entering directory `/usr/local/src/grass/svn/lib/vector/diglib'
  test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu
  gcc -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -g -Wall -Wno-parentheses -Wno-format-zero-length -fPIC -I/usr/local/include -I/usr/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\""grasslibs"\" -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/allocation.o -c allocation.c
  In file included from allocation.c:21:
  /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:479: error: syntax error before '*' token
  /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:479: warning: type defaults to `int' in declaration of `Vect_read_line_geos'
  /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:479: warning: data definition has no type or storage class
  ....
  /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:483: error: syntax error before '*' token
  /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:483: warning: type defaults to `int' in declaration of `Vect_get_isle_points_geos'
  /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:483: warning: data definition has no type or storage class

Lines 479-483 of vector.h are:

  GEOSGeometry *Vect_read_line_geos(struct Map_info *, int, int*);
  GEOSGeometry *Vect_line_to_geos(struct Map_info *, const struct line_pnts*, int);
  GEOSGeometry *Vect_read_area_geos(struct Map_info *, int);
  GEOSCoordSequence *Vect_get_area_points_geos(struct Map_info *, int);
  GEOSCoordSequence *Vect_get_isle_points_geos(struct Map_info *, int);

The error indicates that it doesn't understand the types. No surprise
there, as neither GEOSGeometry nor GEOSCoordSequence appear in my
version of geos_c.h (GEOS 2.2.3). However, it does have:

typedef struct GEOSGeom_t *GEOSGeom;
typedef struct GEOSCoordSeq_t *GEOSCoordSeq;

If I add typedefs for GEOSGeometry and GEOSCoordSeq, everything
compiles okay.

[I have no idea whether it works, but it compiles, and doesn't appear
to break anything.]

I've committed r38878, which restores the configure checks, and adds
adds workarounds for the issues with GEOS 2.x. Someone needs to check
that these don't break 3.x.

initGEOS or GEOSGeom_createLinearRing are defined in GEOS C API (geos_c)...

Right; those are there. I had the impression[1] that this was a
3.x-specific symbol; and much confusion ensued.

[1] Mainly from:

http://lists.osgeo.org/pipermail/grass-dev/2009-August/045435.html

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

martinl · August 27, 2009, 6:42am

Hi,

2009/8/26 Glynn Clements <glynn@gclements.plus.com>:

[...]

I've committed r38878, which restores the configure checks, and adds
adds workarounds for the issues with GEOS 2.x. Someone needs to check
that these don't break 3.x.

thanks, backported to devbr6 in r38879.

Martin

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

Hamish · August 27, 2009, 9:42am

Glynn:

I've committed r38878, which restores the configure checks, and adds
adds workarounds for the issues with GEOS 2.x. Someone needs to check
that these don't break 3.x.

great, I can report that 6.5svn now ./configures and builds --with-geos
ver 2.2.3 successfully, and that 'v.select --help' shows new options.

in related issues swig/python/ still fails to build due to too-old(?)
swig ver 1.3.29, but the ./configure check just checks for the presence
of /usr/bin/swig; it doesn't test if that contains what we need.
It would be nice if it could be made to work with older versions of swig
again, & if not, at least the ./configure script should throw an error
when --with-python is given instead of doing what it does now & fail at
compile-time.

thanks,
Hamish

Glynn_Clements1 · August 27, 2009, 1:11pm

Hamish wrote:

in related issues swig/python/ still fails to build due to too-old(?)
swig ver 1.3.29, but the ./configure check just checks for the presence
of /usr/bin/swig; it doesn't test if that contains what we need.
It would be nice if it could be made to work with older versions of swig
again, & if not, at least the ./configure script should throw an error
when --with-python is given instead of doing what it does now & fail at
compile-time.

AFAIK, that version with SWIG will work with older versions of Python.
The core problem is that your distro ships a version of of SWIG which
isn't compatible with their version of Python (or have you upgraded
Python manually?).

A configure check would need to use SWIG to generate a Python wrapper,
then try to compile it.

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

Hamish · August 27, 2009, 1:30pm

Hamish wrote:
> in related issues swig/python/ still fails to build due to
> too-old(?) swig ver 1.3.29, [...]

Glynn:

AFAIK, that version with SWIG will work with older versions of Python.
The core problem is that your distro ships a version of of SWIG which
isn't compatible with their version of Python

Debian/Etch, swig 1.3.29-2.1, 2.4.4-3+etch2.

Swig+python used to work on this machine up until a couple of months
ago, about the time of the automatic .h -> .i changes. I don't really
know but I figured the two were related somehow.
I should check the archives, I've got a funny feeling this has been
explained to me a number of times already. (hence my suspicion that
my copy of swig was too old now)

(or have you upgraded Python manually?).

nope; but it is slighly possible a security update package gone wrong
might have altered something.

A configure check would need to use SWIG to generate a
Python wrapper, then try to compile it.

FWIW the error is as so:

[...]
gcc -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -ggdb -march=pentium4 -Wall -Werror-implicit-function-declaration -fPIC -DPACKAGE=\""grasslibs"\" -fPIC -I/usr/include/python2.4 -I/usr/include/python2.4 -DPACKAGE=\""grasslibs"\" -I/usr/include/gdal -I/usr/include/gdal -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/utils_wrap.o -c utils_wrap.c
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2495: error: (Each undeclared identifier is reported only once
utils_wrap.c:2495: error: for each function it appears in.)
utils_wrap.c:2495: error: expected ';' before 'len'
utils_wrap.c:2522: error: 'len' undeclared (first use in this function)
utils_wrap.c: In function 'pyobj_to_ptr':
utils_wrap.c:2570: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2570: error: expected ';' before 'len'
[...]

thanks,
Hamish

Glynn_Clements1 · August 27, 2009, 3:46pm

Hamish wrote:

FWIW the error is as so:

[...]
gcc -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -ggdb -march=pentium4 -Wall -Werror-implicit-function-declaration -fPIC -DPACKAGE=\""grasslibs"\" -fPIC -I/usr/include/python2.4 -I/usr/include/python2.4 -DPACKAGE=\""grasslibs"\" -I/usr/include/gdal -I/usr/include/gdal -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/utils_wrap.o -c utils_wrap.c
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2495: error: (Each undeclared identifier is reported only once
utils_wrap.c:2495: error: for each function it appears in.)
utils_wrap.c:2495: error: expected ';' before 'len'
utils_wrap.c:2522: error: 'len' undeclared (first use in this function)
utils_wrap.c: In function 'pyobj_to_ptr':
utils_wrap.c:2570: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2570: error: expected ';' before 'len'

Oops. It's not your distro; utils.i and my_typemaps.i are using
Py_ssize_t although that type only exists in Python 2.5. Later
versions of SWIG define it (as an alias for "int") for earlier
versions of Python.

Try this:

--- swig/include/python/common.i (revision 38884)
+++ swig/include/python/common.i (working copy)
@@ -2,6 +2,13 @@
#include <stdio.h>
#include <grass/gis.h>
#include <grass/raster.h>
+
+#if PY_VERSION_HEX < 0x02050000 && !defined(PY_SSIZE_T_MIN)
+typedef int Py_ssize_t;
+# define PY_SSIZE_T_MAX INT_MAX
+# define PY_SSIZE_T_MIN INT_MIN
+#endif
+
%}

%rename(my_def) def;

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

Hamish · August 28, 2009, 2:06am

Glynn wrote:

Try this:

--- swig/include/python/common.i (revision 38884)
+++ swig/include/python/common.i (working
copy)
@@ -2,6 +2,13 @@
#include <stdio.h>
#include <grass/gis.h>
#include <grass/raster.h>
+
+#if PY_VERSION_HEX < 0x02050000 &&
!defined(PY_SSIZE_T_MIN)
+typedef int Py_ssize_t;
+# define PY_SSIZE_T_MAX INT_MAX
+# define PY_SSIZE_T_MIN INT_MIN
+#endif
+
%}

%rename(my_def) def;

yes, with that patch a fresh build completes successfully.

thanks,
Hamish