[SciPy-user] C++ extensions

[Robert Kern]

David Grant wrote:

> I tried doing what you describe.  I basically am doing the following as 
> a test to see if I can get this to work.  I have the following test 
> python script:
> 
> import weave
> inc_dirs=['/home/david/working_dir/python/qcd', '/usr/include']
> lib_dirs=['/home/david/working_dir/python/qcd', '/usr/lib']
> libs=['dcomplex']
> code = """
> #include "DComplex.h"
> DComplex z(2,3);
> """
> weave.inline(code, include_dirs=inc_dirs, library_dirs=lib_dirs, 
> libraries=libs, verbose=2)

I'm pretty sure that you want to put all #include's as support code. 
Everything in 'code' gets pasted into a function body.

E.g.

support_code = """#include "DComplex.h"
"""
code = """DComplex z(2,3);
"""
weave.inline(code, support_code=support_code, ...)

> DComplex.cpp and DComplex.h define a class for complex numbers.  I build 
> DComplex.cpp separately using a makefile. This does:
> 
> gcc -c DComplex.cpp
> ar rc libdcomplex.a DComplex.o
> ranlib libdcomplex.a
> 
> This builds a static library libdcomplex.a  Then, as shown in my test 
> python script above, I use libs=['dcomplex'] and that will include 
> libdcomplex.a in the current directory.  The linking actually seems to 
> work ok!  The prooblem seems to be when python imports the file:

When linking shared libraries, the linker will often (always?) not check 
for missing symbols.

> running build_ext
> customize UnixCCompiler
> customize UnixCCompiler using build_ext
> building 'sc_89dfe56fc9f6dd6ee19b60174c27c7511' extension
> compiling C++ sources
> g++ options: '-fno-strict-aliasing -DNDEBUG -fPIC'
> compile options: '-I/home/david/working_dir/python/qcd -I/usr/include 
> -I/usr/lib/python2.3/site-packages/weave 
> -I/usr/lib/python2.3/site-packages/weave/scxx -I/usr/include/python2.3 -c'
> g++: 
> /home/david/.python23_compiled/sc_89dfe56fc9f6dd6ee19b60174c27c7511.cpp
> g++ -pthread -shared 
> /tmp/david/python23_intermediate/compiler_d039d257d176c3731283eef034e62e43/home/david/.python23_compiled/sc_89dfe56fc9f6dd6ee19b60174c27c7511.o 
> /tmp/david/python23_intermediate/compiler_d039d257d176c3731283eef034e62e43/usr/lib/python2.3/site-packages/weave/scxx/weave_imp.o 
> -L/home/david/working_dir/python/qcd -L/usr/lib -ldcomplex -o 
> /home/david/.python23_compiled/sc_89dfe56fc9f6dd6ee19b60174c27c7511.so
> 
> Traceback (most recent call last):
>  File "test_weave.py", line 20, in ?
>    weave.inline(code,['arr','_Narr'], include_dirs=inc_dirs, 
> library_dirs=lib_dirs, libraries=libs, verbose=2)
>  File "/usr/lib/python2.3/site-packages/weave/inline_tools.py", line 
> 335, in inline
>    auto_downcast = auto_downcast,
>  File "/usr/lib/python2.3/site-packages/weave/inline_tools.py", line 
> 445, in compile_function
>    exec 'import ' + module_name
>  File "<string>", line 1, in ?
> ImportError: 
> /home/david/.python23_compiled/sc_89dfe56fc9f6dd6ee19b60174c27c7511.so: 
> undefined symbol: _ZZ13compiled_funcP7_objectS0_EN8DComplexC1Edd
 >
> As you can see above there is an undefined symbol in the python .so 
> extension, which ends in ...DComplex...

The stuff before it, ...compiled_func... points, I believe to the fact 
that the #include came inside the function body whereas the library 
needs it outside of the function body.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter