[C++-sig] Problems with link stage... (Number 2)

[Jeff Holle]

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
     <include>/usr/local/include/python2.3
     <find-library>UMLModel <library-path>.
   :
     release
   ;

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?



Second part:

I've got more information about my problem via experimentation.
First, I cleaned up my Jamfile to:
subproject cppTest ;
import python ;

exe cppTest
:  # sources
  cppTest.cpp
:  # requirements
  <find-library>python2.3
  <find-library>UMLModel <library-path>.
:
  release
  ;

In doing "bjam -a -n", I can see that both "-lpython2.3" and 
"-lUMLModel" are properly feed to the linker.

I get the same 130 link errors has above with python2.3, but when I try 
python2.2 it is reduced to a single link error, concerning 
"PyCFunction_NewEx".  Info found on the web about this is that it was 
changed from a function to a macro at some time in the past.

Also, I installed python 2.3.3 and rebuilt everything.  Nothing changed.

Last, I find that both python 2.3.2 and python 2.3.3 builds did not 
produce a shared library equivalent to libpython2.3.a.  Maybe this is a 
problem?