Re: Python and debug STLport (was: Re: nocygwin toolset)

From: Raoul Gough (raoulgough_at_[hidden])
Date: 2002-05-13 06:22:24

From: "David Abrahams" <david.abrahams_at_[hidden]>
Sent: Friday, May 10, 2002 11:23 AM
Subject: Re: [boost] Re: nocygwin toolset (was: Re: Contributing new
toolsetsupport)

> Moving this to jamboost_at_yahoogroups.com...

Yes, sorry about the mis-directed post. I typed the wrong list name by
mistake.

> From: "Raoul Gough" <RaoulGough_at_[hidden]>
[snip]
> > I guess I'll have to put together the changes necessary to build an
> > NT-native jam using cygwin gcc.
>
> I'm sure the jam executable itself is fine, modulo small changes that may
> need to be made to the Jambase... hmm, no, there appears to be something
> wrong with the way commands are invoked. A Jam built under Cygwin can
> bootstrap itself, but when used in Boost.Build there is some kind of
> problem. If you use
>
> jam <options> -ofile <targets>
>
> It will write a file which you can invoke iwith the shell, FWIW.

I had (probably) the same problem with the cygwin build, but removing the
assignments of JAMSHELL in tools/build/jam_src/Jambase and
tools/build/allyourjambase.jam fixed the problem for me. I thought you'd
already integrated these changes, though, so I'm not sure what's going on
here.

[snip]
> Dynamic linking (except to the runtime) is a property of the target you're
> building; you can't select it that way. Sometimes even the method of
> linking to the runtime is constrained by a target's requirements. If you
> want <runtime-link>dynamic only, you can just put it in your BUILD
> variable:
>
> -sBUILD="release <runtime-link>dynamic"

Great! Thanks for this info - I couldn't find anything that directly
answered this question in the docs.

[snip]

> > There is one remaining problem with python, but it only occurs in the
> debug
> > build. The module is question is libs\python\example\simple_vector.cpp.
> > Could it be something to do with vector iterator not being a pointer?
> It's
> > being compiled with STLport's debug STL via -D_STLP_DEBUG and produces:
> >
> > d:/boost/CVS/boost/boost/python/caller.hpp: In function `static struct
> > PyObject * boost::python::caller<unsigned
> > int>::call<_STL::__vector<double,_STL::allocator<double> > >(size_t
> > (_STL::__vector<double,_STL::allocator<double> >::*)() const, PyObject
*,
> > PyObject *)':
> > d:/boost/CVS/boost/boost/python/detail/functions.hpp:73: instantiated
> from
> > `boost::python::detail::wrapped_function_pointer<unsigned int,unsigned
> int
> > (_STL::__vector<double,_STL:
> > :allocator<double> >::*)() const>::do_call(PyObject *, PyObject *)
const'
> > f:/stlport/STLport-4.5.3/stlport/stl/debug/_iterator.h:153:
> instantiated
> > from hered:/boost/CVS/boost/boost/python/caller.hpp:232: no matching
> > function for call to `from_python (PyObject *&,
> > boost::python::type<_STL::__vector<double,_STL::allocator<double> > &>)'
>
> I don't think so. Not sure what the problem is there.

I think I've tracked this problem down. Here's an example which demonstrates
the limitation that is causing the problem with the STLport debug STL:

-------------------

#include <boost/python/class_builder.hpp>
namespace python = boost::python;

struct base
{
int foo () const { return 0; }
};

struct derived : public base { };

BOOST_PYTHON_MODULE_INIT(simple_vector)
{
python::module_builder this_module("simple_vector");
python::class_builder<derived> builder (this_module, "derived");

builder.def (&derived::foo, "foo"); // Boom
}

--------------

The type of &derived::foo is pointer to *base* member function - ummm, I
guess you'd write this int (base::*)() const. Anyway, the compiler seems to
barf on this because class_builder was instantiated with derived, and it
won't deal with a call to the base class member function (even with public
derivation). I don't understand enough about boost::python to say why this
should be.

Now, the really unfortunate thing about this is that, when _STLP_DEBUG is
defined, the STLport vector (_STL::vector) is actually derived from the
otherwise non-existant _STL::__vector (these are the real identifiers after
macro expansions). This base class defines all the handy member functions,
so their types don't match the class builder which is, of course,
instantiated with _STL::vector.

Close attention to the original error message actually does identify the
problem: the "no matching function" error indicates that the actual type
involves __vector and the long list of candidate functions has entries
only for vector without the underscores. There seems to be an inherent
incompatability between boost::python and at least some of the STLport
containers in debug mode.

Regards,
Raoul Gough.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com