[BUG]: undefining _DEBUG breaks build on VS 2022

[libbooze]

Required prerequisites

• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
• Consider asking first in the Gitter chat room or in a Discussion.

Problem description

After updating to VS2022 my build was broken, I originally reported it to Microsoft, but turns out it is probably pybind bug.

You are not allowed to undef _DEBUG macro.

https://github.com/pybind/pybind11/search?q=_DEBUG

Reproducible example code

My code was broken in Debug build in VS 2022, I used 2.6, but master seems to have same undef.

[snnn]

I think the primary reason is we can’t build numpy in debug mode(with the debug version msvcrt). ONNX and ONNX Runtime follow the same pattern. Either they all define the macro, or they all should undef it.

[fsb4000]

related: #3403

[libbooze]

I think the primary reason is we can’t build numpy in debug mode(with the debug version msvcrt). ONNX and ONNX Runtime follow the same pattern. Either they all define the macro, or they all should undef it.

Is this some limitation in MSVC or something in numpy is broken under debug build? From what I understand in other issue MSFT has 0 intention of supporting people undefining _DEBUG (and I agree with them, although I know very little about build hacks like this)

[henryiii]

You can always set Py_DEBUG to disable the hiding of _DEBUG as a workaround, by the way.

[Skylion007]

Relevant issue: #1713 (comment)

[WillemvJ]

You can always set Py_DEBUG to disable the hiding of _DEBUG as a workaround, by the way.

Not sure if I understand this. Tried to add (in cmakelists.txt):

target_compile_definitions(pybind_example PUBLIC Py_DEBUG=1) 

but that didn't work. Can build pybind module in release, but unfortunately not in debug at present on VS2022.

[guban]

Py_DEBUG can be set as

target_compile_definitions(pybind_example PUBLIC Py_DEBUG)

After that, the project compiles, but there are linker errors saying that python38_d.dll is not found. After adding that to path (a quick hard-coding hack: target_link_directories(pybind_example PRIVATE "C:/Programs/Python38/libs")), it compiles and links, but fails at runtime with debug assertion in pystate.c:

Expression: gilstate->autoInterpreterState

So, setting Py_DEBUG does not really help.

[petersteneteg]

think this is fixed in #3497

[zhengzh]

Encountered the same problem on vs2019, I use vcpkg to install the latest python3.10 and pybind11

[snnn]

Not directly related, but I think it is still important to let all of you know that recently one of my colleagues found another issue:
When you use the undef _DEBUG hack then run the built binary, actually it will load two CRTs: ucrtbase.dll and ucrtbased.dll. Though they are separated, they still need to share file descriptors like stdout/stderr. It might look like stdout is only initialized in ucrtbase.dll but not ucrtbased.dll, or vice versa. Because the process won't initialize the same stream twice. For example, if you have code like:

setlocale(LC_ALL, "");

Would it have impact to the both CRT copies or just one?
What if the two stdout streams have different mode(binary vs text) or state?

It is a headache. I don't feel it is worth to continue thinking about these questions.

[hakolj]

Have this been fixed? I still encounter the error C2039: '_invalid_parameter': is not a member of '`global namespace'' when I compile with DEBUG flag. Compling with RELEASE is all good. My environment is Cmake 3.15 and MSVC14.29 (Cmake with vs2019)