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

Reply via email to