Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: try newer images #3480

Closed
wants to merge 4 commits into from
Closed

ci: try newer images #3480

wants to merge 4 commits into from

Conversation

henryiii
Copy link
Collaborator

@henryiii henryiii commented Nov 18, 2021

Description

It seems MSVC 2022 is causing some issues (#3459, #3477). Let's try it explicitly.

Suggested changelog entry:

@henryiii
Copy link
Collaborator Author

henryiii commented Nov 18, 2021

So it seems removing _DEBUG meddling fixes the issue with needing the extra include (that is from an optional component), but reintroduces the original LINK : fatal error LNK1104: cannot open file 'python35_d.lib' type errors.

@snnn
Copy link
Contributor

snnn commented Nov 22, 2021

From my understanding, in that case you will need to used python_d.exe instead of python.exe to run the package. Then I will lose numpy because I don't know how to build numpy in such a way.

@henryiii
Copy link
Collaborator Author

Yes, this is why we disable _DEBUG when including Python.h unless this is a Py_DEBUG build. Python.h can't include C++ sources, though, so I don't know why MSVC 2022 is unhappy. I'm not sure adding a PYBIND11_KEEP_YOUR_HANDS_OFF_DEBUG variable would actually provide a way around the problem due to that.

@libbooze
Copy link

Yes, this is why we disable _DEBUG when including Python.h unless this is a Py_DEBUG build. Python.h can't include C++ sources, though, so I don't know why MSVC 2022 is unhappy.

Not a STL person but I read their comments as:
your undefing of _DEBUG breaks their code because they think they can use a function that is not available in release version of their libs, so linker errors happen.
microsoft/STL#2335 (comment)

also they say _DEBUG is NOT a customization point so you are not allowed to do what you do (I learned from that issue that clang even has a warning when you mess with reserved identifiers).
microsoft/STL#2335 (comment)

tl;dr I don't think MS will ever agree to supporting this, if you explain underlying issue why originally you undef _DEBUG then maybe somebody reading this will be able to figure out a different hack/solution.

If something like that is not feasible then maybe just add to README that debug build is not supported.

@henryiii
Copy link
Collaborator Author

99% of users making debug builds want to debug their code, not CPython itself; they usually don't have a CPython debug library and wouldn't know how to link to it even if they did. That's why we do this. If there's another way to get CPython to not require the debug library but to still build user code in debug mode, I'm all ears. :)

@libbooze
Copy link

libbooze commented Nov 23, 2021

If there's another way to get CPython to not require the debug library but to still build user code in debug mode, I'm all ears. :)

Thank you for reply. I think best would be to ask CPython people if they would support this, maybe they can make their dependency in debug configurable.

Beside that I think this hack might work:

#3477 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants