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 <pyconfig.h> 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.)
In article <slrnb83icj.1eg.do-not-spam-ben.hutchings@tin.businesswebsoftware.com>, I wrote:
Also, make sure you include <pyconfig.h> 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 <yg-boost-users@m.gmane.org> writes:
In article <slrnb83icj.1eg.do-not-spam-ben.hutchings@tin.businesswebsoftware.com>, I wrote:
Also, make sure you include <pyconfig.h> 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 <yg-boost-users@m.gmane.org> writes:
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 <pyconfig.h> 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 <yg-boost-users@m.gmane.org> writes:
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 <pyconfig.h> 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 <pyconfig.h> 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 <pyconfig.h> before any system header on all platforms, but we found out the hard way that this leads to problems with VC and Codewarrior under Windows. We still need to look at this issue very carefully and do a lot of testing on all platforms with all combinations of debug, debug-python and release builds. At the moment I am thinking a start would be to rework boost/python/detail/wrap_python.hpp and include it everywhere we currently have the Tru64-only <pyconfig.h> includes in the 1.30.0 release. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
Ben Hutchings -
David Abrahams