Python interpreter embedded in the application fails to load native modules

Question

I have an application that statically links to libpython.a (2.7). From within the application's interpreter I try importing time module (time.so), which fails with:

ImportError: ./time.so: undefined symbol: PyExc_IOError

So, this module has unresolved symbols:

nm -D time.so | grep PyExc_IOError
         U PyExc_IOError

I figured that this symbol is discarded by the linker when linking the application. OK, I'm now linking libpython with all symbols:

... -Wl,-whole-archive -lpython -Wl,-no-whole-archive ...

The symbol is now there:

$ nm app | grep PyExc_IOError
8638348 D PyExc_IOError
08638ca0 d _PyExc_IOError

But I still get the same import error. Where is the problem?

Are you following the steps in the embedding guide? Compiling with distutils? — Eli Bendersky, Nov 19 '10 at 09:09
@Eli, yep, it's right there. My gnat-like attention span was not enough to make it until the last paragraph. — Alex B, Nov 19 '10 at 09:18

score 2 · Accepted Answer · answered Nov 19 '10 at 11:04

Besides making sure all of libpython is included in your binary, you also need to make sure the symbols in the library are exposed to shared objects being loaded. When you're linking libpython (statically) into your main binary this means you need the --export-dynamic linker argument (so -Wl,--export-dynamic or -Xlinker --export-dynamic as the gcc argument.) When loading a shared object with libpython (say, when you embed libpython into a plugin for your app) this means you have to make sure the shared object is loaded with the RTLD_GLOBAL flag to dlopen().

Python interpreter embedded in the application fails to load native modules

1 Answers1

Linked