<div dir="ltr">AbstractSTRtree doesn't look particularly interesting at first glance. I only see a few linter issues like param names that don't match, a redundant return on void method<div><br></div><div>:(</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 10:04 AM, Sean Gillies <span dir="ltr"><<a href="mailto:sean.gillies@gmail.com" target="_blank">sean.gillies@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Kurt,<br><br></div>Thanks for the sympathy!<br><br></div>It's the same library version. Same library build, even. I have a system that builds GEOS once, copies it into the two Python package trees, and uses install_name_tool to relink all the Python .so modules. <a href="https://github.com/matthew-brett/delocate" target="_blank">https://github.com/matthew-bre<wbr>tt/delocate</a> (if you're curious) wraps both install_name_tool and otool and is what the SciPy team uses to make binary wheels (the Python distribution format) for numpy, scipy, pandas etc.<br><br>$ delocate-listdeps --all ~/Downloads/scipy-1.0.0-cp27-c<wbr>p27m-macosx_10_6_intel.macosx_<wbr>10_9_intel.macosx_10_9_x86_64.<wbr>macosx_10_10_intel.macosx_10_<wbr>10_x86_64.whl<br>/System/Library/Frameworks/Acc<wbr>elerate.framework/Versions/A/<wbr>Accelerate<br>/usr/lib/libSystem.B.dylib<br>/usr/lib/libstdc++.6.0.9.dylib<br>@loader_path/../../../../.dyli<wbr>bs/libgcc_s.1.dylib<br>@loader_path/../../../../.dyli<wbr>bs/libgfortran.3.dylib<br>@loader_path/../../../../.dyli<wbr>bs/libquadmath.0.dylib<br>@loader_path/../../../.dylibs/<wbr>libgcc_s.1.dylib<br>@loader_path/../../../.dylibs/<wbr>libgfortran.3.dylib<br>@loader_path/../../../.dylibs/<wbr>libquadmath.0.dylib<br>@loader_path/../.dylibs/libgcc<wbr>_s.1.dylib<br>@loader_path/../.dylibs/libgfo<wbr>rtran.3.dylib<br>@loader_path/../.dylibs/libqua<wbr>dmath.0.dylib<br>@loader_path/libgcc_s.1.dylib<br>@loader_path/libquadmath.0.dyl<wbr>ib<br><br></div>This works like a charm for SciPy packages, which don't have overlapping dependencies like shapely and fiona do, and also works fine for shapely and fiona outside of the AbstractSTRTree module.<br><br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 12:22 PM, Kurt Schwehr <span dir="ltr"><<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ouch :(<br></div><div><br></div><div>Some thoughts... you might be getting different versions of the library (e.g. different compiler versions or flags for the same version of libgeos). otool -L and dtrace are places to start, but aren't fun. Is it happening on multiple machines? Using macports, fink, homebrew, or for the libs?</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-8746072172601474944h5">On Wed, Jan 3, 2018 at 10:34 AM, Sean Gillies <span dir="ltr"><<a href="mailto:sean.gillies@gmail.com" target="_blank">sean.gillies@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-8746072172601474944h5"><div dir="ltr"><div><div><div><div><div>Hi and Happy New Year, all.<br><br></div>I found time recently to make notes on a frustrating issue that I'm having with GEOS in the Shapely binary wheels for OS X that I'm publishing on PyPI. I'm not certain whether there's a GEOS bug, a dynamic loader bug, a ctypes bug, misuse of computers on my part, or all four. I'd really appreciate a bit of advice from anyone with more C++ and Mach-O wisdom that would rule out a few of these possibilities.<br><br></div>Here's the gist of it: Shapely uses dlopen (via Python's ctypes) to load libgeos_c.dylib at run time. The GEOS C++ library (libgeos-3.6.2.dylib, for example) is a dependent library of libgeos_c.dylib. I have been distributing the GEOS libs with my Shapely binaries for convenience of users, but Shapely also works with GEOS installed to the standard places on your system. I've never experienced or seen report of a problem with Shapely's loading of the GEOS libraries *in isolation* that hasn't been fixed.<br><br></div>My Fiona package for Python also depends on libgeos_c.dylib, but in the more familiar way: it's a dependent library of GDAL, which is loaded when Fiona's C extension modules are loaded in Python.<br><br></div>If we import fiona in a Python script and then import shapely from a binary wheel that includes GEOS libraries, the script will abort in either AbstractSTRtree::query or AbstractSTRtree::itemsTree because the dynamic casts yield null pointers. As far as I can tell, loading two copies of the C++ GEOS library is where the trouble starts. Is the trouble in the loader, the library code, or my builds? I do not know.<br><br></div>There's no problem on Linux. The Linux library loader may be more foolproof or the library code might be compiled more correctly in a way that I don't yet see. I'm using the following flags in my builds – the dual architecture build is the only thing that seems unusual to me.<br><pre>environment =
MACOSX_DEPLOYMENT_TARGET=10.9
configure-options =
CFLAGS="-arch i386 -arch x86_64 -O2 -Wl,-S -Wall -Wstrict-prototypes"
CXXFLAGS="-arch i386 -arch x86_64 -O2 -Wl,-S -Wall -Wstrict-prototypes"
LDFLAGS="-arch i386 -arch x86_64"</pre><div><div><div><div><div><div><div>The thing that makes me suspect that there is a localized bug in GEOS is that loading the library twice doesn't lead to failures in computing areas, lengths, predicates, or WKT serializations. Only in the AbstractSTRtree module as far as I can tell.</div></div><div><br></div><div>I've made a ticket at <a href="https://trac.osgeo.org/geos/ticket/848" target="_blank">https://trac.osgeo.org/geos/ti<wbr>cket/848</a> and have attached a script that reproduces the problem as well as demonstrating that other GEOS modules are unaffected.</div><div><br></div><div>It's interesting, but mostly baffling and humbling to go so deep into the weeds of dynamic library loading. I'm over my head here and super grateful for insights and discussion.</div><span class="m_-8746072172601474944m_1436712829042409227HOEnZb"><font color="#888888"><div><br></div><div><div>-- <br><div class="m_-8746072172601474944m_1436712829042409227m_2458577872541812615gmail_signature">Sean Gillies</div>
</div></div></font></span></div></div></div></div></div></div>
<br></div></div>______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/geos-devel</a><span class="m_-8746072172601474944HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="m_-8746072172601474944HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-8746072172601474944m_1436712829042409227gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/geos-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br></div></div><span class="HOEnZb"><font color="#888888"><div class="m_-8746072172601474944gmail_signature" data-smartmail="gmail_signature">Sean Gillies</div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/geos-devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>