Jeff Holle <jeff.holle at verizon.net> writes:
> trying to build a cpp test client of my python extension shared
> library, which uses boost.python.
>
> I'm using linux with gcc v3.3, python v2.3.2, boost 04/01/26 CVS head.
>
> I've successfully built a boost.python extension module and tested it
> with python.
> Now I'm stuck at the link stage of an equivalent C++ client.
>
> The problem is my link is failing with "unresolved references" like:
> PySequence_DelSlice' PyNumber_InPlaceXor' PyNumber_Subtract'
> PyMem_Malloc' PyComplex_RealAsDouble'
> PyModule_Type' PySequence_DelSlice' PyNumber_InPlaceXor'
> They mostly emulate from the boost_python library.
>
> In investigating what Python 2.3.2 gives to my linux system, I've only
> found that the likely cantigate is libpython2.3.a.
> Including this library to my bjam file appears to have no affect.
> My current Jamfile is:
>
> subproject cppTest ;
> import python ;
> exe cppTest
> : # sources
> cppTest.cpp
> : # requirements
> <lib>../../../Python-2.3.2/libpython2.3.a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Won't work for various reasons.
> <include>/usr/local/include/python2.3
> <find-library>UMLModel <library-path>.
> :
> release
> ;
To build a Python embedding application with Boost.Python, add:
<lib>@boost/libs/python/build/boost_python
to your sources, and:
$(PYTHON_PROPERTIES)
<define>BOOST_PYTHON_STATIC_LIB
<define>BOOST_PYTHON_STATIC_MODULE
<library-path>$(PYTHON_LIB_PATH)
<$(gcc-compilers)><debug-python><library-path>$(CYGWIN_PYTHON_DEBUG_DLL_PATH)
<$(gcc-compilers)><*><library-path>$(CYGWIN_PYTHON_DLL_PATH)
<find-library>$(PYTHON_EMBEDDED_LIBRARY)
to your requirements. Should be easier, I know :(.
You can see a working example in libs/python/test/Jamfile
> A more general question:
> My experience with linux and gcc is much more limited to my windows
> programming background.
> In windows, problems like this where the client of a dll gains an
> appetite for resources used only by the dll points to a problem of
> the client code using something other than an abstract interface from
> the dll.
>
> I have modified my shared library to only use abstract interfaces.
> Note this involves a simple class factory. This procedure has not
> altered the linking problems that I have.
>
> Does linux share this problem with windows, MSVC 6.0 sp5?
Shared libraries on Linux are different, but I've got no time to do a
complete explanation now. I'm really Sorry! The info is out there.
HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com