Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
Glynn wrote: > Try this: > > --- swig/include/python/common.i(revision 38884) > +++ swig/include/python/common.i(working > copy) > @@ -2,6 +2,13 @@ > #include > #include > #include > + > +#if PY_VERSION_HEX < 0x0205 && > !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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
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 #include #include + +#if PY_VERSION_HEX < 0x0205 && !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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
Hi, 2009/8/26 Glynn Clements : [...] > 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 * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
2009/8/26 : > 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 * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
