C API in debug fails

[Banger]

BPO	21292
Nosy	@loewis, @pitrou

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2014-04-17.21:51:18.732>
labels = ['expert-C-API', 'type-bug', 'library']
title = 'C API in debug fails'
updated_at = <Date 2020-06-25.09:40:09.653>
user = 'https://bugs.python.org/Banger'

bugs.python.org fields:

activity = <Date 2020-06-25.09:40:09.653>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'C API']
creation = <Date 2014-04-17.21:51:18.732>
creator = 'Banger'
dependencies = []
files = []
hgrepos = []
issue_num = 21292
keywords = []
message_count = 6.0
messages = ['216759', '216760', '216785', '216786', '216853', '217147']
nosy_count = 3.0
nosy_names = ['loewis', 'pitrou', 'Banger']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21292'
versions = ['Python 3.3']

[Banger]

Although not a bug, it annoys me enough that it is a bug in my head!

The problem is that trying to compile an application in debug that embeds Python fails.

Case in point; we canned the idea of embedding Python (went with Lua) for that reason only. We did not have the option of incorporating a Python build into our build system and not being able to compile in debug was not an option either. We would have been happy to compile in debug with a release lib of Python, but since it was not possible, it got killed.

The fix: It should be possible for someone to compile an application in debug that embeds python without having the Python debug libraries.

[pitrou]

Is that under Windows?

[Banger]

It is under windows

[Banger]

A bit more info:

• When building in debug you need the Pythonxx_d.lib.
• This lib does not come with the normal install (or any other install). That part is fine and normal (you don't include debug libs with install).
• To get that lib you have to build Python in debug to get it. This is too much, I should not have to rebuild a library just because I want to build MY application in debug.
• Copying the Pythonxx.lib file to Pythonxx_d.lib works for many basic functions, but for others, it is missing necessary defiitions (i.e. linking fails).

[loewis]

I think the issue is actually slightly different. You can certainly build your Python "in debug", and still link with the release mode Python. The question is what "in debug" means, and the normal definition would be "with the generation of debug symbols by the compiler".

What you cannot do is

1. to build with _DEBUG defined (or whatever the exact spelling of the macro is, or
2. to link with the debug version of msvcrt.

We could fix 1, i.e. allowing you to define _DEBUG, and still bind the release version. I think we cannot reasonably fix 2; this is a Microsoft issue.

You can work around by simply not defining _DEBUG, and still build "in debug"

[Banger]

Indeed, but not defining _DEBUG for debug compiling is not realistic. Too many dependencies. I am not even sure it would work, because if we bind with the debug libraries, but build with the "release" headers, it might break. In any case it is not an option we have on the table at this moment.

As for the linking part, I am not sure I am following you. Your runtime libraries and DLLs should not need to be linked to anything. They may be dependent on the release msvcrt, and that is fine (like I said, we can live with the Python parts in release). We have many other such libraries that are only in release mode (even when we build in debug).

[vstinner]

Since Python 3.8, Python built in debug mode is ABI compatible with Python built in release mode.

There is no activity on this issue for 9 years. I close the issue.

[zooba]

Since Python 3.8, Python built in debug mode is ABI compatible with Python built in release mode.

This is not quite true for Windows, but as long as you don't expect consistent process-wide state then it's usually fine.

Even so, there's nothing for us to fix here, so closing the issue is correct.