This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Joakim.Karlsson
Recipients Joakim.Karlsson
Date 2014-09-14.17:57:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
When I embed Python 3.4 in an existing app, I run in to a few issues when our app is built in debug mode. I build against the headers, libs and dlls that I get when installing python, I don't build python myself.

1. When I include python.h it will, via pyconfig.h, automatically attempt to link to python34_d.lib. This lib, along with its accompanying dll is not included in the python installation.

I'd rather explicitly link to the release lib than having header files implicitly selecting libs based on the _DEBUG flag. I ended up killing the #pragma comment(lib...) statements in pyconfig.h, and I can now link with the lib included.

2. Now when I build, I get a linker error telling me that '__imp__Py_RefTotal' and '__imp_Py_NegativeRefCount' cannot be found. This seems to be caused by Py_DEBUG being defined automatically in pyconfig.h as a result of _DEBUG being defined for my application. This causes the reference counting macros to use functionality that is only present in the debug version of python34.dll.

I ended up including pyconfig.h first, undefed Py_DEBUG, and then including python.h. This seems rather clunky.

Keeping with "explicit is better than implicit", wouldn't it be better to having to explicitly link to the desired lib from the embedding app, and explicitly set Py_DEBUG without having it inferred from _DEBUG? 

That way the provided headers and libs would work right out of the box while still leaving me the option to get the debug behaviour if I need to.
Date User Action Args
2014-09-14 17:57:04Joakim.Karlssonsetrecipients: + Joakim.Karlsson
2014-09-14 17:57:04Joakim.Karlssonsetmessageid: <>
2014-09-14 17:57:04Joakim.Karlssonlinkissue22411 messages
2014-09-14 17:57:04Joakim.Karlssoncreate