0

I compiled SimpleElastix for both Windows and Linux months ago. The SimpleElastix build process produced a .so file under Linux and a .pyd under Windows for use with Python. I was able to import SimpleElastix under python 3.6 in both Linux and Windows and use the library, no problem.

Fast forward to now. I've upgraded to python 3.10. I am still able to import SimpleElastix under Linux using the same .so, but I cannot do the same under Windows. Python 3.10 cannot find the .pyd file no matter what I do. I tried adding the location to PATH, PYTHONPATH, and even os.add_dll_directory. I'm pretty sure if I simply re-built SimpleElastix with Python 3.10 in my PATH, it would probably work. The only trouble is, the project seems semi dead and the build process is currently broken due to unpinned dependencies.

My question is: Are pyd files only importable against a single specific python version (the one it was linked against)? It seems so since examples I read online for creating pyd files involve passing i.e. -lpython36 to the compiler. Is there a way to build pyd files like Linux .so files that don't have that limitation? Is there a way to "relink" a .pyd against a newer python version without access to the original build?

Gillespie
  • 5,780
  • 3
  • 32
  • 54
  • libpython reserves the right to make ABI-incompatible changes between minor releases; only point-releases are guaranteed to retain ABI compatibility. – Charles Duffy Nov 19 '22 at 23:19
  • Do you know why .pyd files need to be linked against libpython but .so files do not? – Gillespie Nov 19 '22 at 23:20
  • ...to be clear about how one can retain API compatibility but break ABI compatibility, think about renaming a function but creating a preprocessor directive to redirect calls to the old name to use the new one; code will still compile, but it _has_ to be recompiled; relinking will fail. That's even more true if you're doing things like extending a struct to add more members (changing its size), or adding new arguments to a function (changing the stack layout used when calling it) while having the preprocessor paper over the changes, etc. – Charles Duffy Nov 19 '22 at 23:21
  • Eh? Many .so files _do_ link against libpython. Depends on the details of the individual project -- if you're using ctypes, f/e, then it's native Python code responsible for knowing how to bridge the gap. – Charles Duffy Nov 19 '22 at 23:21
  • Just because they do doesn't mean they must, correct? Looks like you can compile a `.so` with `-fPIC` etc and the resulting library is importable by python. But it appears you cannot do the same with pyd – Gillespie Nov 19 '22 at 23:24
  • (...in all honesty, I grok .so files a lot more than I do .pyd; I'm a Unix developer, not a Windows person) – Charles Duffy Nov 19 '22 at 23:24
  • `.so` isn't Python-specific at all, and the whole point of ctypes is to use arbitrary C libraries from Python. Now, is there a format for C modules written in Python that _is_ Python-specific and version-dependent? Yes, absolutely. But not every `.so` used from Python is in that format. (Similarly, on Windows you can use ctypes to link to functions in a DLL that doesn't itself link to libpython) – Charles Duffy Nov 19 '22 at 23:25
  • On the other hand, .so files used from Python _in the same way as .pyd files_ **are** in the aforementioned version-specific format (compiled against a given release's headers), and attempting to use them from different Python releases from the one they were compiled against is not supported. So if you're asserting that you can take a Python C module from Python 3.5 and load it from Python 3.6... that's very much not supported. – Charles Duffy Nov 19 '22 at 23:27

0 Answers0