[GRASS-dev] Re: [GRASS-SVN] r51583 - grass/trunk/vector/v.buffer

[Glynn Clements]

Markus Neteler wrote:

> > Author: mmetz
> > Date: 2012-05-01 01:37:26 -0700 (Tue, 01 May 2012)
> > New Revision: 51583
> >
> > Modified:
> >   grass/trunk/vector/v.buffer/Makefile
> > Log:
> > add again GEOSLIBS ??? should be included by VECTORLIB
> 
> I have this:
> 
> [neteler at north grass70]$ grep geos include/Make/*
> include/Make/Platform.make:GEOSLIBS            = -L/usr/lib64 -lgeos -lgeos_c

If you add the -i flag (ignore case), you would get many more matches,
including:

include/Make/Grass.make:VECT_CFLAGS =  $(GDALCFLAGS) $(GEOSCFLAGS)
include/Make/Grass.make:VECTORDEPS       = $(DBMILIB) $(GRAPHLIB) $(DIG2LIB) $(LINKMLIB) $(RTREELIB) $(GISLIB) $(GEOSLIBS) $(GDALLIBS) $(MATHLIB) $(BTREE2LIB) $(GPROJLIB) $(RASTERLIB) $(PQLIBPATH) $(PQLIB)

> but without GEOSLIBS in the Makefile of v.buffer I get this error:

> /usr/bin/ld: OBJ.x86_64-unknown-linux-gnu/main.o: undefined reference
> to symbol 'GEOSBufferParams_create'

If GRASS was configured --with-geos, GEOS should be pulled in by
libgrass_vector.so. It's possible that you're linking against a
version of libgrass_vector which was built without GEOS support, or
which was linked against a different major version of the GEOS
library.

OTOH, as v.buffer is now using GEOS directly, $(GEOSLIBS) and
$(GEOSCFLAGS) should be used in v.buffer/Makefile. While this
shouldn't be necessary on Linux, I suspect that it is necessary on
Windows.

For me, the current v.buffer doesn't even compile, due to
GEOSBufferParams not being defined in any GEOS header (presumably it
needs a more recent version of GEOS).

> Since you also have Fedora16, I wonder why it compiles for you and not for me
> without GEOSLIBS in the Makefile of v.buffer.

Probably because either:

1. If shared libraries are used, GEOS should get pulled in
automatically as a dependency of libgrass_vector.so.

2. If static libraries are used, $(VECTORDEPS) (which includes
$(GEOSLIBS)) will be added to the definition of VECTORLIB.

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