CMake should prefer the shared versions of libraries. Is there a: /usr/lib/python2.4/config/libpython2.4.so on your machine?
Since CMake uses -L, I am thinking there must not be a linkable .so in the same directory as the .a. Where is your shared version of python located? -Bill At 05:43 PM 2/21/2006, James Bigler wrote: >So FindPythonLibs seems to favor the static version of python that is found in >/usr/lib/python?.?/config . > >This is find and dandy until you try to call some swigged code from an >embedded python interpreter. > >Swig will compile an interface library (called _example.so). This will be >statically linked against /usr/lib/python2.4/config/libpython2.4.a as per the >FindPythonLibs's PYTHON_LIBRARIES variable. > >Now I compile another shared library (called libscene_python.so) that contains >the embedded python code, so I need to link against >/usr/lib/python2.4/config/libpython2.4.a again. > >My main program then dynamically loads libscene_python.so which starts up the >python interpretor. This interpreter eventually calls the swig code inside >_example.so. However, because each library was compiled using the static >version of the library, there are in actually *2* interpreters floating around >in memory space from each of the instantiations of the statically linked >library. > >If you link against a shared version of libpython, life is good, because there >is only one "python core" in memory. > >I was able to do this, by hard coding the library from the static one to the >shared one. Is there a way to control this better than this manual tweak or >to favor the shared versions of libraries? > >Thanks, >James >_______________________________________________ >CMake mailing list >[email protected] >http://www.cmake.org/mailman/listinfo/cmake _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
