SWIG problems - "ImportError: dynamic module does not define......."

[Chris Hodapp]

I have seen messages posted about this before, and there is a clear
reference to it in the manual, but I have been unable to find a
solution.

I'm on Slackware 9.1, kernel 2.6.0-test11, using Python 2.3.1 and
GCC 3.2.3 (both installed by default with Slackware) and SWIG 1.3.19,
compiled from source code.
I messed around a little on my own and couldn't get things to work
right,
so I copied the examples from the book, nearly verbatim but with some
minor changes to fit my configuration.

I copied the example code exactly into example.i and example.c, and
did
the following commands:
swig -python example.i
gcc -c example.c example_wrap.c -I/usr/include/python2.3
ld -shared example.o example_wrap.o -o _example.so
.... and several other times in the last command I tried some other
things like examplemodule.so and example.so. All of these worked
without
error, so I tried it from within Python, and got the usual error about
"ImportError: dynamic module does not define init function" when I
tried
'import example'. It made no difference if I added the path with all
the
files to sys.path; the same error occurred.

I tried this several times over, and I could never get it to work
right. The last helpful suggestion I saw on here was that I did not
make the init<whatever> function public by putting
/EXPORT:init<whatever> on the linker line, but that doesn't seem to be
what GNU ld understands

Any suggestions?

Thanks,
-Chris

 

[Richard Sharp]

Hello,
I am not at my home office at the moment but you will probably find the
following link helpful:

http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=utf-
8&threadm=mailman.999029862.20314.python-
list%40python.org&rnum=7&prev=/groups%3Fhl%3Dde%26ie%3DUTF-8%26oe%3Dutf-
8%26q%3Dpython%2Bdistutils%2Bexport%26sa%3DN%26tab%3Dwg

The content is:
Section 5.2 of the Extending and Embedding the Python Interpreter says:
"The problem is that some entry points are defined by the Python runtime
solely for extension modules to use. If the embedding application does not
use any of these entry points, some linkers will not include those entries
in the symbol table of the finished executable. Some additional options are
needed to inform the linker not to remove these symbols.
Determining the right options to use for any given platform can be quite
difficult, but fortunately the Python configuration already has those
values.
To retrieve them from an installed Python interpreter, start an interactive
interpreter and have a short session like this: '-Xlinker -export-dynamic'
The contents of the string presented will be the options that should be
used.
If the string is empty, there's no need to add any additional options. The
LINKFORSHARED definition corresponds to the variable of the same name in
Python's top-level Makefile."
The '-Xlinker' tells gcc to pass '-export-dynamic' to ld. gcc itself seems
to ignore it otherwise.

Richard Sharp

(e-mail address removed) (Chris Hodapp) wrote in

 

[Chris Hodapp]

Hello,
I am not at my home office at the moment but you will probably find the
following link helpful:

http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=utf-
8&threadm=mailman.999029862.20314.python-
list%40python.org&rnum=7&prev=/groups%3Fhl%3Dde%26ie%3DUTF-8%26oe%3Dutf-
8%26q%3Dpython%2Bdistutils%2Bexport%26sa%3DN%26tab%3Dwg

Richard Sharp

Thank you. That information, along with GCC's manual pages, helped me
to get everything working. What eventually worked was 'gcc example.c
example_wrap.c -I/usr/include/python-2.3 -Xlinker -export-dynamic
-shared -o _example.c'.

-Chris