You are right, it is not from GEOS but from an older PostGIS install.
Even so, the problem of two versions of liblwgeom.h remains. The reason
is that liblwgeom.h in /usr/local is only updated at "make install".
Before that, the compiler sees the older version when compiling a new
version of PostGIS. But only when there is an explicit -I directive for
/usr/local/include, *and* that directive precedes the include directive
for the PostGIS source tree.That is not a very common case, it only
happens when you compile as non-root to non-standard install
directories. Even so, it would be better to use an explicit path when
including liblwgeom.h (../liblwgeom.h/liblwgeom.h)
Jan
On 06/23/2012 02:41 AM, Sandro Santilli wrote:
On Fri, Jun 22, 2012 at 09:27:59PM +0200, Jan Hartmann wrote:
Compiling PostGIS 2.0.0 will break down when the file "liblwgeom.h"
is not included from the PostGIS distribution, but from the
installed GEOS includes. This happens when the include path to the
gcc compiler first explicitly specifies the standard include
directories (/usr/include etc), and only afterwards the specific
PostGIS include directories, like "-I/usr/local/include
-I../libwgeom". The problem is that the file "liblwgeom.h" exists
both in the GEOS distribution and in the PostGIS source. Things are
defined differently im both versions, i.e. a "struct BOX3D" with and
without a "srid" member.
There's no liblwgeom.h in GEOS, as far as I know.
Maybe you refer to a previous installation of PostGIS ?
--strk;
Sent from our free software
http://www.gnu.org/philosophy/free-sw.html
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users