python segmentation fault

[Karl Grossner]

Hello

I'm trying to get python bindings for s2geometry going in my venv. Followed the instructions on the Github README, adding Python support, adding -DWITH_PYTHON=ON to the cmake command. Got a setup.py file, created a wheel file, and did a `pip install` on that - all without error. In my Python 3.10 shell I tried `import s2geometry` and get booted out of the shell instantly with the error: "[1]    89345 segmentation fault  python"

This is Mac OS Ventura 13.3, M1 Macbook Pro

Any idea what my next steps might be? The goal is to generate S2 cell identifiers for a bunch of geometries - points, lines, polygons.

thanks

[resent with system info and without typos]

[Brian Miles]

Hello,

I just built a wheel from a Homebrew Python 3.10 virtual environment on macOS 13.4. After installing the wheel, I also get a segfault when running `import s2geometry`. Are you also using Homebrew? Do you also have Python 3.11 installed? I do. And while building the 3.10 wheel, I noticed that CMake was finding Homebrew's Python 3.11:

...

-- Found SWIG: /opt/homebrew/bin/swig (found suitable version "4.1.1", minimum required is "4.0")  

-- Found Python3: /opt/homebrew/Frameworks/Python.framework/Versions/3.11/bin/python3.11 (found version "3.11.4") found components: Interpreter Development Development.Module Development.Embed 

...

My guess is that this is the source of the issue since CPython 3.11 and CPython 3.10 don't have ABI compatibility.

I would suggest building the 3.10 wheel from within a macOS VM that only has Python 3.10 installed. Or if you have time, you can monkey with CMake environment variables to see if you can coax it use the Python 3.10 headers/etc.

Let us know how it turns out and/or add updates to the README and issue a PR.

Thanks,

Brian

[Karl Grossner]

Hello Brian

This does seem like the cause. I have 3 or 4 homebrew Python versions (!), which I never explicitly use, as I build a fresh venv for each project. They seem to have been installed by other homebrew installs. Looking at the CMakeCache.txt file I see reference to the brew 3.11, although my working 3.10 is active. When I tried to uninstall the homebrew 3.11 version, it complained about a dependency.

So yes, a vm sounds like the ticket. Thanks much for the reply and the catch. Traveling in the next few days, but will report back the solution after that.

cheers, Karl

--
You received this message because you are subscribed to a topic in the Google Groups "s2geometry-io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/s2geometry-io/n7HwiJZ2y5I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to s2geometry-i...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/s2geometry-io/8ab40a22-3970-4f31-b04f-2674291147a2n%40googlegroups.com.

-- 
Karl Grossner, PhD
Technical Director, World Historical Gazetteer
ka...@kgeographer.org
@kgeographer
Visting researcher, University of Vienna through Aug 2023

[Karl Grossner]

Finally got to tackling this. Yes, the compile issue was caused by the make logic finding a Python@11 version, despite an active 3.10 environment. Turned out I could remove (unlink) my brew @11 version without harm elsewhere, it found @10, and built a wheel that works. Thanks again. Wound up with an implementation issue regarding MultiPolygons I'll make as another thread. Thanks again.