[Community] rtree not loading correctly

[Brian Burke]

Recap: I was having problems importing rtree because it was compiled
under 64-bit and the libspatialindex.dll file was 32-bit.

I loaded the 64-bit version of libspatialindex that Howard compiled.
Other than an error about a file named msvcp100.dll (which I don't think
was related to my rtree issue and was resolved by installing this file),
the new version ran great. Thanks for your help!!
-Brian

[Howard Butler]

Recap: I was having problems importing rtree because it was compiled under 64-bit and the libspatialindex.dll file was 32-bit.
I loaded the 64-bit version of libspatialindex that Howard compiled. Other than an error about a file named msvcp100.dll (which I don't think was related to my rtree issue and was resolved by installing this file), the new version ran great. Thanks for your help!!

As Brian said, I have 64bit windows versions compiled via MSVC 2010. I'm not quite sure how to include them in our existing Rtree PyPI binaries, however. What does Shapely do for 64bit builds? Any ideas how to proceed here?

Howard

[Sean Gillies]

Recap: I was having problems importing rtree because it was compiled under 64-bit and the libspatialindex.dll file was 32-bit.
I loaded the 64-bit version of libspatialindex that Howard compiled. ?Other than an error about a file named msvcp100.dll (which I don't think was related to my rtree issue and was resolved by installing this file), the new version ran great. Thanks for your help!!

As Brian said, I have 64bit windows versions compiled via MSVC 2010. ?I'm not quite sure how to include them in our existing Rtree PyPI binaries, however. What does Shapely do for 64bit builds? ?Any ideas how to proceed here?

Shapely's installers ship a DLL that gets installed in
site-packages/shapely as geos.dll and then we instruct ctypes to find
it relative to shapely/geos.py. Jaakko makes sure that the right DLL
is in the right installer. It's got the same name whether 32 or 64
bit.

Are you working on Rtree at the sprint?

[Howard Butler]

Post by Sean Gillies

Post by Howard Butler

Recap: I was having problems importing rtree because it was compiled under 64-bit and the libspatialindex.dll file was 32-bit.
I loaded the 64-bit version of libspatialindex that Howard compiled. Other than an error about a file named msvcp100.dll (which I don't think was related to my rtree issue and was resolved by installing this file), the new version ran great. Thanks for your help!!

As Brian said, I have 64bit windows versions compiled via MSVC 2010. I'm not quite sure how to include them in our existing Rtree PyPI binaries, however. What does Shapely do for 64bit builds? Any ideas how to proceed here?

Shapely's installers ship a DLL that gets installed in
site-packages/shapely as geos.dll and then we instruct ctypes to find
it relative to shapely/geos.py. Jaakko makes sure that the right DLL
is in the right installer. It's got the same name whether 32 or 64
bit.
Are you working on Rtree at the sprint?

Jaako,

When I build Rtree on windows, it simply names the .egg or .exe with win32.{egg|exe} and no information about the 32/64bitness of the library. Were you manually setting these filenames, or is there some incantation that I should be invoking to get the right behavior? Otherwise, I'm simply leaning toward embedding both the 64 and 32 bit dlls in the single windows egg/exe, and having the import select the correct one based on the sizeof(ctypes.c_void_p).

Howard

[Jaakko Salli]

Hello Howard,

Post by Howard Butler

Post by Sean Gillies
Shapely's installers ship a DLL that gets installed in
site-packages/shapely as geos.dll and then we instruct ctypes to find
it relative to shapely/geos.py. Jaakko makes sure that the right DLL
is in the right installer. It's got the same name whether 32 or 64
bit.

When I build Rtree on windows, it simply names the .egg or .exe with
win32.{egg|exe} and no information about the 32/64bitness of the library.
Were you manually setting these filenames, or is there some incantation
that I should be invoking to get the right behavior? Otherwise, I'm simply
leaning toward embedding both the 64 and 32 bit dlls in the single windows
egg/exe, and having the import select the correct one based on the
sizeof(ctypes.c_void_p).

Calling setup.py bdist_wininst and bdist_egg with the same Python
version (32- or 64-bit, as appropriate) should be enough. At least that
is what I do and it adds the 'win-amd64' platform identifier for the 64-bit
packages.

Oh, and Sean, sorry for not updating Windows packages for the 1.2.14, done
now. Somehow I missed the announcement.

Regards,
Jaakko