Re: bjam issue related to boost::python
In article <23681.5566233874$1028263753@news.gmane.org>, Srivatsan Raghavan wrote:
hi all , i created a c++ extension module using python which worked fine..
then i wanted to embed a call to PyRun_SimpleFile in another app, and the script i was calling is attempting to use my extension module
but i was getting telling me that the interpreter wasn't initialized after much searching, research, and work with msvc's Dependency Walker i narrowed it down to the fact that boost_python_debug.dll is trying to link to the release version of python22.dll , whereas it should be linking to python22_d.dll (which unfortunately does not come with the python installer , that has to be compiled manually )
at any rate, how can the boost::python Jamfile be modified to try this check when it comes boost::python ?
This is correct. The 'debug' configuration is meant to work with a
release version of Python, though I don't know why. However, there is
no need to modify the Jamfile; just use the 'debug-python' configuration
instead. Also, make sure you include
In article
Also, make sure you include
before any of the Boost.Python headers, because not all of them do that and you can end up with incorrect structure definitions in a debug build if you don't. (I should report this bug.)
This is not correct. Somehow I managed to build a program where different DLLs were using different structure definitions and on investigation it *seemed* that a Boost.Python header was at fault. On reexamination of Boost.Python I don't believe this is the case. My apologies to David Abrahams.
Ben Hutchings
In article
, I wrote: Also, make sure you include
before any of the Boost.Python headers, because not all of them do that and you can end up with incorrect structure definitions in a debug build if you don't. (I should report this bug.) This is not correct. Somehow I managed to build a program where different DLLs were using different structure definitions and on investigation it *seemed* that a Boost.Python header was at fault. On reexamination of Boost.Python I don't believe this is the case. My apologies to David Abrahams.
No apologies needed. It is, technically a bug which affects a few (perverse) platforms. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Ben Hutchings
In article <23681.5566233874$1028263753@news.gmane.org>, Srivatsan Raghavan wrote:
hi all , i created a c++ extension module using python which worked fine..
then i wanted to embed a call to PyRun_SimpleFile in another app, and the script i was calling is attempting to use my extension module
but i was getting telling me that the interpreter wasn't initialized after much searching, research, and work with msvc's Dependency Walker i narrowed it down to the fact that boost_python_debug.dll is trying to link to the release version of python22.dll , whereas it should be linking to python22_d.dll (which unfortunately does not come with the python installer , that has to be compiled manually )
at any rate, how can the boost::python Jamfile be modified to try this check when it comes boost::python ?
This is correct. The 'debug' configuration is meant to work with a release version of Python, though I don't know why.
Because most Python developers neither have nor know how to build a debug version of Python, and the debug build is the default for testing. There's no reason they should be prevented from debugging their extension modules.
However, there is no need to modify the Jamfile; just use the 'debug-python' configuration instead. Also, make sure you include
before any of the Boost.Python headers, because not all of them do that and you can end up with incorrect structure definitions in a debug build if you don't. (I should report this bug.)
We know about it; it only affects a few platforms and we think we have the right answer for the next release, IIRC. Ralf can confirm/deny that, though... -- Dave Abrahams Boost Consulting www.boost-consulting.com
Ben Hutchings
This is correct. The 'debug' configuration is meant to work with a release version of Python, though I don't know why. However, there is no need to modify the Jamfile; just use the 'debug-python' configuration instead. Also, make sure you include
before any of the Boost.Python headers, because not all of them do that and you can end up with incorrect structure definitions in a debug build if you don't. (I should report this bug.)
Ralf says:
However, there is no need to modify the Jamfile; just use the 'debug-python' configuration instead. Also, make sure you include
before any of the Boost.Python headers, because not all of them do that and you can end up with incorrect structure definitions in a debug build if you don't. (I should report this bug.) We know about it; it only affects a few platforms and we think we have the right answer for the next release, IIRC. Ralf can confirm/deny that, though...
We know about it, but I don't think we have the right answer. I was
hoping the right answer is to include
participants (2)
-
Ben Hutchings
-
David Abrahams