What is inside SO file of Python library distribution?

Question

I have a library, which consists of 3 files which are intended to be put in site python directory.

FbxCommon.py
fbxsip.so
fbx.so

Once these files are in place, Python can see fbx package. How does this system work? What is inside SO file?

If it is a DLL how can it be python version-dependent (it works with python 3.3 but doesn't work with python 3.5)

UPDATE

Distinguishing code is following

from fbx import *
lSdkManager = FbxManager.Create()

on Python 3.3 it just does nothing, while on Python 3.5 it throws this error:

Traceback (most recent call last):
  File "/opt/pycharm-2017.2.2/helpers/pydev/pydevd.py", line 1599, in <module>
    globals = debugger.run(setup['file'], None, None, is_module)
  File "/opt/pycharm-2017.2.2/helpers/pydev/pydevd.py", line 1026, in run
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "/opt/pycharm-2017.2.2/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "/home/dims/PycharmProjects/FBXCheck/fbxcheck.py", line 2, in <module>
    lSdkManager = FbxManager.Create()
AttributeError: type object 'FbxManager' has no attribute 'Create'

Proviso

I don’t understand the question are you writing a library and asking about imports? – Elson

I am not writing a library, I am interested in architecture details. How can SO file work for Python 3.3 but doesn't work for Python 3.5 – Proviso

Answer 1

.PYD files on Windows are .DLLs with a Python interface.

On Linux, both of these use .SO as the extension. So your files are probably Linux binaries with the Python interface (init function etc.), which is why they can be simply imported by Python, without using ctypes or something similar.

When compiling, those extension modules need to be linked against the respective .so (.dll on Windows) of Python, so in this case probably python33.so was used. When running Python 3.5, the reference to python33.so cannot be resolved, since only python35.so is loaded. So that fails. You will need to use the version linked specifically to your Python version.

Update

I just tried to import that same module with Python 3.6 on Windows, which gave me

ImportError: DLL load failed: The specified module could not be found.

Which is exactly what I'd expect from running the wrong Python version.

Maybe in your installation the python33.so exists elsewhere, is then found and loaded, but since you're actually running from Python 3.5, it rejects initialization, including that of the module, which later on leeds to the error.

I guess you're out of luck running these libraries without the correct version of the Python interpreter. Maybe have a look at virtualenv if you want to be able to swap versions easily.

Bootle

But I see no any linking errors, I see messages, that some member functions are not found. – Proviso

Can you show me how you tried to import it, and what message exactly it showed? – Bootle

Can you explain, why DYNAMIC linking library can be such version specific? The nature of DYNAMIC is that linking occurs at runtime and should not contain absolute addresses isn't? – Proviso

Your import makes a dynamic load of that library, yes, but that library itself is statically linked to that speicifc Python binary. – Bootle