The pre-release sdist is at
http://gispython.org/dist/Shapely-1.0.15.tar.gz
Works fine on my linux2 and darwin machines. I've no sunos5 or win32,
but I'm certain the latter will work. Linux, OS X, and Windows users
don't really have to upgrade at all.
On Mar 18, 2010, at 1:22 PM, Nicholas Bower wrote:
sure - let me know where it is but i'll take a couple of days to get
back to you. Ironically i'll have to temporarily drop out ctypes
dependency for the test as that doesn't compile on solaris either
without some poking which i'm trying to fix also.
On Thu, Mar 18, 2010 at 11:04 PM, Sean Gillies
<[email protected]> wrote:
Why not? Would you be willing to test a snapshot sdist? If so, I'm
willing to release 1.0.15 as early as today.
On Mar 18, 2010, at 12:49 PM, Nicholas Bower wrote:
What are the chances of retrofitting this to 1.0 series also
(perhaps the current stable branch for most)?
I've run into this and have had to always drop shapely out of my
setuptools dependencies, building by hand, because of it and don't
want at this time to have to upgrade to 1.2 if I've the choice.
On Thu, Mar 18, 2010 at 10:32 PM, Sean Gillies
<[email protected]> wrote:
I decided to go with the simplest approach for 1.2b4:
http://trac.gispython.org/lab/changeset/1570
It seems that there's a find_library bug involving Solaris
http://mail.python.org/pipermail/new-bugs-announce/2009-February/004177.html
so I'm avoiding it. That function works fine on Linux and OS X.
On Mar 17, 2010, at 3:55 PM, Huw Lynch wrote:
You're right; my problems have been on solaris not using GNU libc. I
don't know quite what the purpose is, but if linked against GNU
libcm platform.libc_ver() returns quite a different result - a
specific libc code version rather than the file system libc version.
If you take a copy of platform.libc_ver(), disable the GLIBC_ match
string (worst case just replace it with GxxxLIBC_ so that it does
not match) then it correctly picks up the libc.so.6 version on linux
too.
I confirm that on solaris 10 with python compiled by Sun Studio
compilers libc.so.1 is required. sys.platform is sunos5
Alternatively or perhaps in addition, it might be worth adding an
override option to shapely so that users of new systems can specify
the libc version in their code.
Cheers & thanks for the quick response.
On 17 March 2010 17:45, Sean Gillies <[email protected]> wrote:
On Mar 17, 2010, at 3:00 AM, Huw Lynch wrote:
Hi
Bug report - is there a better place to post these?
I've temporarily turned off registration on the wiki while I figure
out what to do about spammers, but I'll gladly set you up with a
login.
Shapely has some issues if when not running on linux with libc.so.6
because libc.so.6 is hard-coded into shapely/geos/__init__.py and
not all platforms use v6. Solaris for example uses libc.so.1
can replace this..
free = CDLL('libc.so.6').free
with this which is more portable...
import platform
libc = platform.libc_ver()
free = CDLL(libc[0]+'.so.'+libc[1]).free
Cheers
I tested this on my Linux machine and it doesn't yield the 'libc.so.
6' that we need:
>>> free = CDLL('%s.so.%s' % platform.libc_ver()).free
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/ctypes-1.0.2-py2.4-linux-
i686.egg/ctypes/__init__.py", line 340, in __init__
self._handle = _dlopen(self._name, mode)
OSError: glibc.so.2.3: cannot open shared object file: No such file
or directory
I'm happy to add a new solaris platform section to geos.py. Will you
specify the platform string and double-check that libc_ver() really
returns ('libc', '1') in your situation?
--
Sean
--
Sean
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
