rename example.cpython-311-x86_64-linux-gnu.so to example.so #4738
Conversation
| @@ -159,7 +159,7 @@ Python's ``setuptools`` to build the module, while `cmake_example`_ uses CMake | |||
|
|
|||
| Building the above C++ code will produce a binary module file that can be | |||
| imported to Python. Assuming that the compiled module is located in the | |||
| current directory (in newer version of python, rename the `example.cpython-xxx-linux-gun.so` to `example.so`) , the following interactive Python session shows how to | |||
| current directory (in newer version of python, rename the ``example.cpython-xxx-linux-gun.so`` to ``example.so``) , the following interactive Python session shows how to | |||
There was a problem hiding this comment.
Did you see example.cpython-*.so with python_example, or cmake_example, or both?
@henryiii could this be fixed in the setuptools and/or cmake config?
There was a problem hiding this comment.
You do not want to do this. This is not Python version specific - it's always worked and always been a bad idea. The SOABI that you are removing is how it avoids loading on a version of Python it wasn't compiled for. PyPy won't even load an extension without the SOABI.
There was a problem hiding this comment.
("this" meaning this PR, not this comment)
Is there some problem you are trying to solve? It would help to know what the issue is. Is some setup accedently producing example.so instead of a properly named extension? The pybind11 tools should do this correctly; if you use FindPython directly, you need to pass the SOABI flag (sadly not the default).
There was a problem hiding this comment.
Totally aside: there is a typo (not fixed here, but in the changed line) of linux-gun -> linux-gnu
There was a problem hiding this comment.
Ah, yes, didn't see that. Pretty sure we aren't accepting this unless more info into why it's needed is given. Nothing should be producing binaries without SOABI, so maybe it's a fix somewhere else that's needed.
|
|
|
|
|
It take me a while to figure out I need |
|
Nope, that's not the correct solution. You are building with Python 3.11, then running with IPython that's been installed with Python 3.10. If you are lucky, it might work, but it will more likely segfault. You can't use a Python 3.x extension with Python 3.y when You need to either build with 3.10 or load it in 3.11. That's one of the reasons for this extension - to protect against that. (Or you can install a kernel for 3.11 and use that with the existing IPython) |
|
(PS: thank you for the clear description with example of what was happening!) |
|
verified works great with correct python version. my bad! Sorry to bother you. |
|
No problem, glad it works now! :) |
No description provided.