From: Charles F. <cha...@th...> - 2006-09-29 09:47:51
|
Hello SWIG users ! I'm wrapping a C++ library for python. My python module (let's say module.py ) is obviously linked to a .so (again, let's say _module.so). As I want my library to be used by C++ program, I compile it : module.so The point is _module.so is basically module.so + python specific code. Is there a way to have _module.so dynamically linked to module.so in order to reduce the size (and avoid to have my compiled classes in two different libraries) ? Thank you a lot ! -- Charles Fleche The Mill, London |
From: Paul M. <p.e...@ru...> - 2006-09-29 11:54:34
|
Charles Fleche wrote: >>What makes you think that _module.so is NOT dynamically linked to the >>shared library that holds your C++ library? >>SWIG does not include all your C++ code in the wrapper it generates. >>It merely makes calls to your library. >> >> > >Strange... Because currently I have just module.py and _module.so, >without module.so and it works well. > But what is your workflow from SWIG interface to final compiled python module? I can do this: swig -c++ -python DummyMath.i g++ -o _DummyMath.so -shared -fPIC DummyMath_wrap.cxx DummyMath.cpp -I /usr/include/python2.4 and then get a _DummyMath.so (which will be imported by DummyMath.py) which is statically linked to the DummyMath classes, in which case you will get code duplication. But if I first compile the DummyMath code into a shared lib with g++ -o libdm.so -shared -fPIC DummyMath.cpp and then compile the SWIG wrapper to use this lib g++ -o _DummyMath.so -shared -fPIC DummyMath_wrap.cxx -I /usr/include/python2.4 then _DummyMath.so IS dependendant on libdm.so: 13:51|melis@hpcv99:~/swigtest/link> ldd _DummyMath.so linux-gate.so.1 => (0xffffe000) libdm.so => ./libdm.so (0xb7ff4000) libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0xb7f23000) libm.so.6 => /lib/libm.so.6 (0xb7f00000) libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so.1 (0xb7ef8000) libc.so.6 => /lib/libc.so.6 (0xb7de0000) /lib/ld-linux.so.2 (0x80000000) 13:52|melis@hpcv99:~/swigtest/link> py Python 2.4.3 (#1, Sep 18 2006, 10:55:37) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import DummyMath >>> dir(DummyMath) ['DummyMathf', 'DummyMathf_swigregister', 'DummyMathi', 'DummyMathi_swigregister', '_DummyMath', '__builtins__', '__doc__', '__file__', '__name__', '_newclass', '_object', '_swig_getattr', '_swig_repr', '_swig_setattr', '_swig_setattr_nondynamic', 'new', 'new_instancemethod'] >>> In this last case you will get the benefit of sharing your code through the libdm.so library. Paul >But I must admit it's a pretty >simple test library, with just a template class in it and create some >instance it in the .i file : > > > >// DummyMath.cpp >#include "DummyMath.h" > >template class DummyMath<float>; >template class DummyMath<int>; > >template<typename T> >DummyMath<T>::DummyMath( T aA, T aB ) : _a( aA ), _b( aB ) >{ >} > >template<typename T> >T DummyMath<T>::add() >{ > return _a + _b; >} > >template<typename T> >T DummyMath<T>::mul() >{ > return _a * _b; >} > > > >// DummyMath.h >template<typename T> >class DummyMath >{ > public: > DummyMath( T, T ); > > T add(); > T mul(); > > private: > T _a; > T _b; >}; > > > > >// DummyMath.i >%module DummyMath >%{ >#include "DummyMath.h" >%} > >%include "DummyMath.h" > >%template(DummyMathf) DummyMath<float>; >%template(DummyMathi) DummyMath<int>; > > > > -- Paul Melis VR Specialist, Center for High-Performance Computing & Visualization, University of Groningen, The Netherlands T: +31 50 363 9298 E: p.e...@ru... W: http://www.rug.nl/rc/hpcv/index |
From: Paul M. <p.e...@ru...> - 2006-09-29 19:42:15
|
Paul Melis wrote: > Charles Fleche wrote: > >>> What makes you think that _module.so is NOT dynamically linked to the >>> shared library that holds your C++ library? >>> SWIG does not include all your C++ code in the wrapper it generates. >>> It merely makes calls to your library. >>> >>> >> Strange... Because currently I have just module.py and _module.so, >> without module.so and it works well. >> > But what is your workflow from SWIG interface to final compiled python > module? > > I can do this: > > swig -c++ -python DummyMath.i > g++ -o _DummyMath.so -shared -fPIC DummyMath_wrap.cxx DummyMath.cpp -I > /usr/include/python2.4 > > and then get a _DummyMath.so (which will be imported by DummyMath.py) > which is statically linked to the DummyMath classes, in which case you > will get code duplication. > > > But if I first compile the DummyMath code into a shared lib with > > g++ -o libdm.so -shared -fPIC DummyMath.cpp > > and then compile the SWIG wrapper to use this lib > > g++ -o _DummyMath.so -shared -fPIC DummyMath_wrap.cxx -I > /usr/include/python2.4 Ugh, this should read g++ -o _DummyMath.so -shared -fPIC DummyMath_wrap.cxx -I /usr/include/python2.4 libdm.so > > then _DummyMath.so IS dependendant on libdm.so: > > 13:51|melis@hpcv99:~/swigtest/link> ldd _DummyMath.so > linux-gate.so.1 => (0xffffe000) > libdm.so => ./libdm.so (0xb7ff4000) > libstdc++.so.5 => > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0xb7f23000) > libm.so.6 => /lib/libm.so.6 (0xb7f00000) > libgcc_s.so.1 => > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so.1 (0xb7ef8000) > libc.so.6 => /lib/libc.so.6 (0xb7de0000) > /lib/ld-linux.so.2 (0x80000000) > > 13:52|melis@hpcv99:~/swigtest/link> py > Python 2.4.3 (#1, Sep 18 2006, 10:55:37) > [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import DummyMath > >>> dir(DummyMath) > ['DummyMathf', 'DummyMathf_swigregister', 'DummyMathi', > 'DummyMathi_swigregister', '_DummyMath', '__builtins__', '__doc__', > '__file__', '__name__', '_newclass', '_object', '_swig_getattr', > '_swig_repr', '_swig_setattr', '_swig_setattr_nondynamic', 'new', > 'new_instancemethod'] > >>> > > In this last case you will get the benefit of sharing your code through > the libdm.so library. > > > Paul > > > >> But I must admit it's a pretty >> simple test library, with just a template class in it and create some >> instance it in the .i file : >> >> >> >> // DummyMath.cpp >> #include "DummyMath.h" >> >> template class DummyMath<float>; >> template class DummyMath<int>; >> >> template<typename T> >> DummyMath<T>::DummyMath( T aA, T aB ) : _a( aA ), _b( aB ) >> { >> } >> >> template<typename T> >> T DummyMath<T>::add() >> { >> return _a + _b; >> } >> >> template<typename T> >> T DummyMath<T>::mul() >> { >> return _a * _b; >> } >> >> >> >> // DummyMath.h >> template<typename T> >> class DummyMath >> { >> public: >> DummyMath( T, T ); >> >> T add(); >> T mul(); >> >> private: >> T _a; >> T _b; >> }; >> >> >> >> >> // DummyMath.i >> %module DummyMath >> %{ >> #include "DummyMath.h" >> %} >> >> %include "DummyMath.h" >> >> %template(DummyMathf) DummyMath<float>; >> %template(DummyMathi) DummyMath<int>; >> >> >> >> > > |