undefined symbol: PyExc_ImportError when embedding Python in C - c

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

#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 2

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

Answer 3

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