[geos-devel] Using SWIG to interface with GEOS, undefined symbols

[strk]

On Mon, Jul 12, 2004 at 04:05:48PM -0600, Sean Gillies wrote:
> On Jul 12, 2004, at 1:13 PM, strk wrote:
> 
> >On Mon, Jul 12, 2004 at 12:15:58PM -0600, Sean Gillies wrote:
> >>
> >>On Jul 12, 2004, at 9:39 AM, strk wrote:
> >>
> >>>On Mon, Jul 12, 2004 at 09:10:53AM -0600, Sean Gillies wrote:
> >>>>On Jul 12, 2004, at 9:00 AM, strk wrote:
> >>>>
> >>>>>On Mon, Jul 12, 2004 at 08:41:07AM -0600, Sean Gillies wrote:
> >>>>>>Hi all,
> >>>>>>
> >>>>>>Yesterday I began to try to use SWIG to generate a Python
> >>>>>>GEOS module using the CVS GEOS.  To start, I am only wrapping
> >>>>>>the classes in geom.h and precision.h.
> >>>>>
> >>>>>precision.h does not really contain 'basic' classes.
> >>>>>PrecisionModel class is in geom.h.
> >>>>>
> >>>>>>SWIG 1.3.20 generates wrapper code with only a few warnings
> >>>>>>and the module does build, resulting in geos.py and a very
> >>>>>>large _geos.so (I have statically linked against libgeos.a).
> >>>>>>
> >>>>>>On import of the geos module, an import error is raised:
> >>>>>>
> >>>>>>ImportError:
> >>>>>>/home/sean/projects/PyGEOS/build/lib.linux-i686-2.3/_geos.so:
> >>>>>>undefined symbol: _ZN4geos14PrecisionModel19maximumPreciseValueE
> >>>>>
> >>>>>Could you have built _geos.so and the geos.py in at different 
> >>>>>times ?
> >>>>>CVS api is changing , and you get those kind of errors for every
> >>>>>simple
> >>>>>'const' addition.
> >>>>>
> >>>>>--strk;
> >>>>>
> >>>>
> >>>>Thanks for the reply!  _geos.so and geos.py are synchronous, no
> >>>>problem
> >>>>there.  I was having this same issue with GEOS 1.0 and SWIG, so I am
> >>>>ruling out API changes.  It's either my lack of knowledge of C++, 
> >>>>some
> >>>>undocumented SWIG issue or a combination of these.
> >>>>
> >>>>Sean
> >>>
> >>>I've checked the code. It seems a bug in both GEOS-1.0 and GEOS-CVS
> >>>PrecisionModel::maximumPreciseValue is never given a value.
> >>>
> >>>geos::maximumPreciseValue is, but the header declare
> >>>geos::PrecisionModel::maximumPreciseValue, which is not.
> >>>
> >>>I've fixed it, please try now.
> >>>
> >>>--strk;
> >>>
> >>
> >>Yes, that one bug seems to be fixed.
> >>
> >>Now there is exposed another one :)
> >>
> >>  ImportError:
> >>/home/sean/projects/PyGEOS/build/lib.linux-i686-2.3/_geos.so:
> >>  undefined symbol:   _ZNK4geos14CoordinateList17toCoordinateArrayEv
> >>
> >>If I direct SWIG to ignore the toCoordinateArray() method of
> >>CoordinateList,
> >>then there is yet another undefined symbol:
> >>
> >>  ImportError:
> >>/home/sean/projects/PyGEOS/build/lib.linux-i686-2.3/_geos.so:
> >>  undefined symbol:
> >>_ZN4geos14CoordinateList3addEPSt6vectorINS_10CoordinateESaIS2_EEb
> >>
> >>Strk, I appreciate that you have taken the time to look into it,
> >>but this might be more time consuming.  I don't know if it will
> >>be possible to SWIG GEOS or if it is in the project's interest to
> >>be altered so that a SWIG module is possible.
> >>
> >>cheers,
> >>Sean
> >
> >Sean, no problem, you might help us as well, as we are redefining
> >the API, so every feedback is appreciated.
> >The problem here is with CoordinateList being currently removed
> >from interface. CoordinateList class reference is still in the
> >geom.h file, but the corresponding module is not built into
> >the library. We are still discussing wheter to keep or not that
> >class. In the meanwhile, I commented out the definition,
> >this should fix your problem.
> >
> >--strk;
> >
> 
> Strk,
> 
> I decided to revert to GEOS-1.0.  Hiding CoordinateList helped,
> but there were then problems with GeometryCollection ... and I
> think I'll try to get it working with 1.0 first.  After a bit of
> tweaking, I have a Python geos module that I can import.
> 
> * applied the change to PrecisionModel.cpp that you committed into
>   the CVS head.
> * directed SWIG to ignore declarations of 'throw_exception' because
>   of an undefined symbol related to Geometry::throw_exception
> * directed SWIG to ignore declarations of 'isClosed' because of an
>   undefined symbol: _ZNK4geos10MultiPoint8isClosedEv
> 
> These last two changes leave the module in a less than fully
> functional state, but I am encouraged.  Any idea what might be
> the problem with Geometry::throw_exception and MultiPoint::isClosed?
> 
> thanks again,
> Sean

Check definition of those functions, which might be missing from GEOS-1.0.
Be warned that next GEOS release will have many API changes, if you can
report GeometryCollection problem that would help in shorten next GEOS release.

--strk;

> 
> Here's a "screenshot" for the curious:
> 
> Python 2.3.3 (#1, Jan  4 2004, 11:27:28)
> [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import geos
> >>> dir(geos)
> ['BasicCoordinateList', 'BasicCoordinateListFactory', 
> 'BasicCoordinateListFactoryPtr', 'BasicCoordinateListPtr', 
> 'Coordinate', 'CoordinateFilter', 'CoordinateFilterPtr', 
> 'CoordinateList', 'CoordinateListFactory', 'CoordinateListFactoryPtr', 
> 'CoordinateListPtr', 'CoordinateList_equals', 
> 'CoordinateList_hasRepeatedPoints', 'CoordinateList_indexOf', 
> 'CoordinateList_minCoordinate', 'CoordinateList_removeRepeatedPoints', 
> 'CoordinateList_reverse', 'CoordinateList_scroll', 'CoordinatePtr', 
> 'Dimension', 'DimensionPtr', 'Dimension_toDimensionSymbol', 
> 'Dimension_toDimensionValue', 'Envelope', 'EnvelopePtr', 
> 'GEOS_GEOMETRYCOLLECTION', 'GEOS_LINESTRING', 'GEOS_MULTILINESTRING', 
> 'GEOS_MULTIPOINT', 'GEOS_MULTIPOLYGON', 'GEOS_POINT', 'GEOS_POLYGON', 
> 'Geometry', 'GeometryCollection', 'GeometryCollectionIterator', 
> 'GeometryCollectionIteratorPtr', 'GeometryCollectionPtr', 
> 'GeometryComponentFilter', 'GeometryComponentFilterPtr', 
> 'GeometryFactory', 'GeometryFactoryPtr', 
> 'GeometryFactory_createPointFromInternalCoord', 
> 'GeometryFactory_toGeometry', 'GeometryFilter', 'GeometryFilterPtr', 
> 'GeometryPtr', 'IntersectionMatrix', 'IntersectionMatrixPtr', 
> 'LineSegment', 'LineSegmentPtr', 'LineString', 'LineStringPtr', 
> 'LinearRing', 'LinearRingPtr', 'Location', 'LocationPtr', 
> 'Location_toLocationSymbol', 'MultiLineString', 'MultiLineStringPtr', 
> 'MultiPoint', 'MultiPointPtr', 'MultiPolygon', 'MultiPolygonPtr', 
> 'Point', 'PointCoordinateList', 'PointCoordinateListFactory', 
> 'PointCoordinateListFactoryPtr', 'PointCoordinateListPtr', 'PointPtr', 
> 'Polygon', 'PolygonPtr', 'PrecisionModel', 'PrecisionModelPtr', 
> 'SFSCurve', 'SFSCurvePtr', 'SFSGeometry', 'SFSGeometryCollection', 
> 'SFSGeometryCollectionPtr', 'SFSGeometryPtr', 'SFSLineString', 
> 'SFSLineStringPtr', 'SFSLinearRing', 'SFSLinearRingPtr', 
> 'SFSMultiCurve', 'SFSMultiCurvePtr', 'SFSMultiLineString', 
> 'SFSMultiLineStringPtr', 'SFSMultiPoint', 'SFSMultiPointPtr', 
> 'SFSMultiPolygon', 'SFSMultiPolygonPtr', 'SFSMultiSurface', 
> 'SFSMultiSurfacePtr', 'SFSPoint', 'SFSPointPtr', 'SFSPolygon', 
> 'SFSPolygonPtr', 'SFSSurface', 'SFSSurfacePtr', '__builtins__', 
> '__doc__', '__eq__', '__file__', '__name__', '_geos', 'cvar', 
> 'greaterThen', 'lessThen', 'point_3d', 'point_3dPtr']
> >>>