undefined symbol: PyExc_ImportError when embedding

Question

I'm developing a C shared library that makes a call to a python script. When I run the application I get this error:

Traceback (most recent call last):
  File "/home/ubuntu/galaxy-es/lib/galaxy/earthsystem/gridftp_security/gridftp_acl_plugin.py", line 2, in <module>
    import galaxy.eggs
  File "/home/ubuntu/galaxy-es/lib/galaxy/eggs/__init__.py", line 5, in <module>
    import os, sys, shutil, glob, urllib, urllib2, ConfigParser, HTMLParser, zipimport, zipfile
  File "/usr/lib/python2.7/zipfile.py", line 6, in <module>
    import io
  File "/usr/lib/python2.7/io.py", line 60, in <module>
    import _io
ImportError: /usr/lib/python2.7/lib-dynload/_io.so: undefined symbol: PyExc_ImportError

If I try to import the module io from console works fine instead:

Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import galaxy.eggs
>>> 

During the compilation of library I've used this compiler option as suggest here : Embedding python in C, undefined symbol: PyExc_ImportError In addition I've added also the compiler options obtained from python-config --includes|--libs|--cflags|--ldflags

Here you can find the log of makefile of library http://pastebin.com/348rhBjM

Thanks a lot, any help will be apreciated.

Answer 1

I use such workaround: explicit linking of plugins from lib-dynload directory (it's simply, then explicit dlopen in code). Example with datetime.so:

cmake:

SET ( CMAKE_SHARED_LINKER_FLAGS "/usr/lib/python2.7/lib-dynload/datetime.so" )

or just add /usr/lib/python2.7/lib-dynload/datetime.so as linker parameter to gcc in command line:

g++ -shared -o libfoo.so foo.o -lbar -lzab /usr/lib/python2.7/lib-dynload/datetime.so

Answer 2

@user1515248 solution is a link-only solution which are discouraged. i am writing this answer to expand on the links he gave and provide a more fleshed out answer (that also backs up the link he gave).

The link, https://mail.python.org/pipermail/new-bugs-announce/2008-November/003322.html, says:

I have been given the following workaround: in mylib.c, before PyInitialize() I can call dlopen("libpython2.5.so", RTLD_LAZY | RTLD_GLOBAL);

This works, but I believe that lib-dynload/*.so should depend on libpython2.5.so.1 so this hack should not be necessary.

I am using Ubuntu 8.04 with Python version 2.5.2-2ubuntu4.1.

All I had to do was add a single line of code:

// new line of code
void*const libpython_handle = dlopen("libpython2.6.so", RTLD_LAZY | RTLD_GLOBAL);

PyInitialize();

p.s. I am on CentOS-6.

p.p.s. My PyInitialize() is wrapped in a class and so dlopen()/PyInitialize() is done in the constructor and dlclose()/PyFinalize() is done in the destructor.

Answer 3

I've found the solution. Maybe can be useful for someone else. It's a bug of python as written here http://mail.python.org/pipermail/new-bugs-announce/2008-November/003322.html I've used the solution posted here http://www.cilogon.org/gsi-c-authz