Rtree installation errors

[Ryan Miller-8]

I'm running into issues installing Rtree.  I've installed  spatialindex-1.4.0 on Ubuntu 9.04 and created the libraries libspatialindex.so, libspatialindex.so.1, and libspatialindex.so.1.0.0.  It appears Rtree is looking for libspatialindex_c.so, therefore when i enter the line "from rtree import core" i get the following message:

...
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from rtree import core
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "rtree/__init__.py", line 8, in <module>
   from index import Rtree
 File "rtree/index.py", line 2, in <module>
   import core
 File "rtree/core.py", line 94, in <module>
   rt = ctypes.CDLL(lib_name)
 File "/usr/lib/python2.6/ctypes/__
init__.py", line 353, in __init__
   self._handle = _dlopen(self._name, mode)
OSError: libspatialindex_c.so: cannot open shared object file: No such
file or directory

I've tried changing the libspatialindex_c.so reference in core.py to libspatialindex.so, but i then recieve an error stating:

OSError: /usr/local/lib/libspatialindex.so: undefined symbol: _ZTVN10__cxxabiv121__vmi_class_type_infoE

Any suggestions would be greatly appreciated.
Thanks,
Ryan


_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies-2]

Rtree 0.5, I presume? It seems that the released code was broken. See  
also

   http://lists.gispython.org/pipermail/community/2009-August/ 
002162.html

Please revert to 0.4.3. I'm going to propose that we pull 0.5, do a  
review, more testing and then make a new release.

Sean

On Sep 12, 2009, at 3:18 PM, Ryan Miller wrote:

> I'm running into issues installing Rtree.  I've installed  
> spatialindex-1.4.0 on Ubuntu 9.04 and created the libraries  
> libspatialindex.so, libspatialindex.so.1, and libspatialindex.so.
> 1.0.0.  It appears Rtree is looking for libspatialindex_c.so,  
> therefore when i enter the line "from rtree import core" i get the  
> following message:
>
> ...
> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
> [GCC 4.3.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from rtree import core
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "rtree/__init__.py", line 8, in <module>
>    from index import Rtree
>  File "rtree/index.py", line 2, in <module>
>    import core
>  File "rtree/core.py", line 94, in <module>
>    rt = ctypes.CDLL(lib_name)
>  File "/usr/lib/python2.6/ctypes/__
> init__.py", line 353, in __init__
>    self._handle = _dlopen(self._name, mode)
> OSError: libspatialindex_c.so: cannot open shared object file: No such
> file or directory
>
> I've tried changing the libspatialindex_c.so reference in core.py to  
> libspatialindex.so, but i then recieve an error stating:
>
> OSError: /usr/local/lib/libspatialindex.so: undefined symbol:  
> _ZTVN10__cxxabiv121__vmi_class_type_infoE
>
> Any suggestions would be greatly appreciated.
> Thanks,
> Ryan
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community

--
Sean Gillies
Programmer
Institute for the Study of the Ancient World
New York University

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Howard Butler-3]

On Sep 12, 2009, at 1:49 PM, Sean Gillies wrote:

> Rtree 0.5, I presume? It seems that the released code was broken. See
> also

libspatialindex_c.so only exists in trunk of libspatialindex.  It has  
not yet been released.  The code was part of 0.5.0, but it was not  
called libspatialindex_c.  To use rtree from trunk, you must also use  
a trunk libspatialindex.  The error below is from this condition.  As  
far as I know, only Brent Pederson and I have been using this so far.

>
>   http://lists.gispython.org/pipermail/community/2009-August/
> 002162.html
>
> Please revert to 0.4.3. I'm going to propose that we pull 0.5, do a
> review, more testing and then make a new release.

Except for the PYTHONPATH/egg issue, which is pretty easy to work  
around, the 0.5 passed all of the tests in the test suite.  Why should  
we retract the release, especially for a software called 0.x instead  
of 1.anything?  I bent over backwards to make sure that the new code  
passed all of the tests in the suite and show that we had functional  
parity with what existed before, and telling people to go back,  
especially considering all of the new functionality (with no  
performance degradation), feels like a smack. In the run up to 0.5.0,  
I was clamoring for testing and heard practically nothing.

In the meantime, Brent and I have continued to work on rtree toward a  
0.6 release, which will include sphinx docs, a bunch of performance  
tweaks by Brent, and the movement of the C/C++ code into  
libspatialindex proper.  The holdup is getting a new libspatialindex  
released, and the holdup on that is I have a few more C API items I  
want to implement for libspatialindex_c like tree walking that can  
make it back into Rtree when we get time.

Let's move forward on releases, not backwards.  When it comes time to  
prep for a release, let's ensure that we're testing stuff more  
widely.  0.5.0 might be a little hinky when it comes to installation,  
and 0.6+ is going to require a specific version of libspatialindex  
(and above).  I guess we could start a maintenance branch using 0.4.x,  
but I'm not helping to maintain it.


>
> On Sep 12, 2009, at 3:18 PM, Ryan Miller wrote:
>
>> OSError: libspatialindex_c.so: cannot open shared object file: No  
>> such
>> file or directory



_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies-2]

On Sep 13, 2009, at 4:32 AM, Howard Butler wrote:

>
> On Sep 12, 2009, at 1:49 PM, Sean Gillies wrote:
>
>> Rtree 0.5, I presume? It seems that the released code was broken. See
>> also
>
> libspatialindex_c.so only exists in trunk of libspatialindex.  It has
> not yet been released.  The code was part of 0.5.0, but it was not
> called libspatialindex_c.  To use rtree from trunk, you must also use
> a trunk libspatialindex.  The error below is from this condition.  As
> far as I know, only Brent Pederson and I have been using this so far.
>
>>
>>  http://lists.gispython.org/pipermail/community/2009-August/
>> 002162.html
>>
>> Please revert to 0.4.3. I'm going to propose that we pull 0.5, do a
>> review, more testing and then make a new release.
>
> Except for the PYTHONPATH/egg issue, which is pretty easy to work
> around, the 0.5 passed all of the tests in the test suite.  Why should
> we retract the release, especially for a software called 0.x instead
> of 1.anything?  I bent over backwards to make sure that the new code
> passed all of the tests in the suite and show that we had functional
> parity with what existed before, and telling people to go back,
> especially considering all of the new functionality (with no
> performance degradation), feels like a smack. In the run up to 0.5.0,
> I was clamoring for testing and heard practically nothing.
>
> In the meantime, Brent and I have continued to work on rtree toward a
> 0.6 release, which will include sphinx docs, a bunch of performance
> tweaks by Brent, and the movement of the C/C++ code into
> libspatialindex proper.  The holdup is getting a new libspatialindex
> released, and the holdup on that is I have a few more C API items I
> want to implement for libspatialindex_c like tree walking that can
> make it back into Rtree when we get time.
>
> Let's move forward on releases, not backwards.  When it comes time to
> prep for a release, let's ensure that we're testing stuff more
> widely.  0.5.0 might be a little hinky when it comes to installation,
> and 0.6+ is going to require a specific version of libspatialindex
> (and above).  I guess we could start a maintenance branch using 0.4.x,
> but I'm not helping to maintain it.

Howard,

The 0.5 sdist release doesn't work. Maybe we just pull that? Feels  
weird to me because IMO the sdist is the canonical release and eggs  
are just for convenience.

--
Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community