[issue22411] Embedding Python on Windows

Steve Dower added the comment: The 3.5 installer contains the option to install the debug binaries, so that side is solved and I'm closing this as fixed. In the video at https://www.youtube.com/watch?v=D9RlT06a1EI I demonstrate how you can build a debug EXE against a release python34.dll witho

[issue22411] Embedding Python on Windows

Steve Dower added the comment: distutils will (now, after some changes in 3.5) build debug versions of packages on installation when running with python_d.exe. I haven't tested exactly how pip behaves here, but it should work fine if you run with a command line like this: python_d.exe -m pip

[issue22411] Embedding Python on Windows

Joakim Karlsson added the comment: Sounds reasonable. It would also require that all third party packages supply a "*_d.pyd" version of any extensions. Does setuptools and pip have any support for automatically creating debug versions of extensions with the correct naming scheme when creating

[issue22411] Embedding Python on Windows

Steve Dower added the comment: Right, so when using python34_d.dll you need the _d.pyd versions (and if you're building your own .pyd you need to add the _d suffix too). There's nothing wrong with this difference, since the debug and release builds are subtly incompatible with each other, so t

[issue22411] Embedding Python on Windows

Joakim Karlsson added the comment: A complicating factor is that the debug and release versions of the dll:s seem to behave differently, which makes it hard to replace one with the other. For instance, in dynload_win.c, the suffix of files looked for are "_d.pyd" in debug mode and ".pyd" in re

[issue22411] Embedding Python on Windows

Steve Dower added the comment: Yeah, unfortunately the only correct way to do this is to use a debug build of Python. It isn't that difficult to build, but it is extra work and may not be an option at all depending on context (for example, some businesses won't let employees access source code

[issue22411] Embedding Python on Windows

Joakim Karlsson added the comment: You shouldn't mix headers with and without the _DEBUG symbol defined. At least on some versions of MSVC this can lead to errors as some standard headers start referencing functions that are not available in both debug and release versions of the MSV C runtime

[issue22411] Embedding Python on Windows

Changes by Antoine Pitrou : -- nosy: +steve.dower, tim.golden, zach.ware ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue22411] Embedding Python on Windows

Rickard Englund added the comment: I have also had this problem. The way I solved it was to undef _DEBUG before including python and then redefine it again: #undef _DEBUG //Prevent linking debug build of python #include #define _DEBUG 1 This is just a hack though and it would be

[issue22411] Embedding Python on Windows

Changes by Ned Deily : -- nosy: +loewis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org

[issue22411] Embedding Python on Windows

New submission from Joakim Karlsson: 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 pyco