pybind11 icon indicating copy to clipboard operation
pybind11 copied to clipboard

[BUG]: undefining _DEBUG breaks build on VS 2022

Open libbooze opened this issue 2 years ago • 10 comments

Required prerequisites

  • [X] Make sure you've read the documentation. Your issue may be addressed there.
  • [X] Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
  • [X] 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.

libbooze avatar Nov 12 '21 22:11 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.

snnn avatar Nov 13 '21 03:11 snnn

related: https://github.com/pybind/pybind11/issues/3403

fsb4000 avatar Nov 13 '21 07:11 fsb4000

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)

libbooze avatar Nov 13 '21 10:11 libbooze

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

henryiii avatar Nov 21 '21 21:11 henryiii

Relevant issue: https://github.com/pybind/pybind11/issues/1713#issue-416071000

Skylion007 avatar Dec 06 '21 16:12 Skylion007

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.

WillemvJ avatar Jan 05 '22 08:01 WillemvJ

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.

guban avatar Jan 26 '22 18:01 guban

think this is fixed in #3497

petersteneteg avatar Feb 28 '22 10:02 petersteneteg

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

zhengzh avatar Aug 04 '22 10:08 zhengzh

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.

snnn avatar Aug 22 '22 22:08 snnn

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)

hakolj avatar Apr 15 '23 14:04 hakolj