c++python-3.x linux shared-libraries ctypes

importing a .py file which imports an .so file via ctypes - error "dynamic module does not define module export function"

I work under Linux.

I wrote a file a.cpp (where there is a function f for which I make an extern "c" {} declaration at the top of the file).
I compiled g++ -shared -fPIC -o a.so a.cpp.
I wrote a.py where I have ctypes.cdll.LoadLibrary('./a.so'). If I actually run this file then everything is fine and I can call the function f.
I wrote b.py which has import a. Here I get an error at that import line: dynamic module does not define module export function (PyInit_a).

I guess I need to somehow modify the import with some __init__ or something, but maybe something else. Does somebody know what to do?

Thanks!

Solution

Listing [Python.Docs]: ctypes - A foreign function library for Python.

There are a couple of ways of overcoming this. The most straightforward is to specify the full path of the .so file. So, if a.py and a.so are inside the same directory (if they are in different directories, computing the relative path would also be trivial), here's what you could do:

dll = ctypes.CDLL(os.path.join(os.path.dirname(os.path.abspath(__file__)), "a.so"))
# ...

This should work on all scenarios. There are some other workarounds (like the one you found) that might work on some of them, but they are influenced by factors like:

Running the code as a script (python a.py) or as a module (python -m a)
The directory where the interpreter is launched from: if it's the same as the one where a.py resides it's fine, but if launching it from outside it might fail

Here I only discussed the trivial case where a.so has no custom dependencies (residing in other places).

Also note that by naming your library a.so (and also having a script a.py), you are confusing the interpreter (to be more precise: import a), which also searches a.so as if it was an extension module ([Python.Docs]: Extending Python with C or C++), that's why you get the (last) ImportError. I'd suggest renaming a.so to something else like:

_a.so (like you already tried): not enforced in any way, but it's some kind of a convention that a module that has the heavy lifting written in C and some Python friendlier interface is split in 2 parts:
1. _some_module*.so (imported by)
2. some_module.py
An example is _ssl*.so and ssl.py
liba.so: I prefer this one as it follows Nix library naming

Of course, if moving towards production, you should give your modules meaningful names.

Might also be helpful: