[C++-sig] Another BPLV2 newbie...

[David Abrahams]

From: "Hugo van der Merwe" <hugo at adept.co.za>


> > If you need support for more arguments, you can set #define
> > BOOST_PYTHON_MAX_ARITY to the number of arguments you need to support.
You
> > can do this on the compiler command-line
with -DBOOST_PYTHON_MAX_ARITY=20
>
> I must rebuild Boost.Python with that parameter I take it.

Technically yes, but practically speaking, no. There is no C++
implementation I know of where it makes a difference what this parameter is
set to when bpl.so is compiled.

>  (Just setting
> it in my code didn't work. Though it did slow down a simple example from
> 5 seconds compile time to 10 seconds... so it did *something* ;)

So, what /did/ happen?

> I will
> try this "tomorrow" (after sleep). (My timezone is "+0200"). For now I
> have commented the .def for the one horrible 17 parameter method...

We already support 17 arguments by default with GCC; maybe you're having a
different problem.

> Interesting thing I did notice, even with this commented, I need to pass
> gcc a -ftemplate-depth-35 parameter (I'm using GCC 2.95.4.
> -ftemplate-depth-34 doesn't work.)

2.95.4 is not an official release of GCC, FWIW, so I'm not officially
supporting it.

> > Don't use "jam"; the executable you want is "bjam" (the name matters).
>
> I ran make in the tools/build/jam_src directory, then I ran
> bin.linuxx86/bjam install

Where did you get the idea to do that?

> - this installed a "jam" named binary only,
> though it is identical to the "bjam" also in that dir. I realise "bjam"
> is to distinguish between boost's jam and the original - I suggest the
> tools/build/jam_src/Jamfile be adjusted to install a "bjam"-named binary
> by default then instead?

"bjam install" was never a prescribed part of the process...

> One last thing I will get back to investigating later:
>
> >>> import test_module
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError:
/home/hugo/Programming/boost/libs/python/bin/libbpl.so/gcc/release/inlining
-on/runtime-link-dynamic/shared-linkable-true/libbpl.so.1.29.0: undefined
symbol: PyType_GenericAlloc
>
> Anyone have a tip to lessen the amount of time I'll spend scratching my
> head?

Looks like a possible mismatch between the python version you're testing
with and the python version you're building with.

-Dave