Fix compilation issues on macOS by conditionally undefining ctype macros#296
Merged
mrbean-bremen merged 2 commits intoMeVisLab:masterfrom Sep 4, 2025
Merged
Conversation
…to avoid libstdc++ <locale> clashes
On older Apple toolchains (e.g., macOS 10.7.4/Xcode 4.3.3 with libstdc++ 4.2.1),
including <Python.h> pulls in <ctype.h>, which defines macros like isspace/isalnum.
When C++ headers such as <locale> (transitively included by moc-generated code)
declare the templated overloads (e.g., `bool std::isspace(_CharT, const std::locale&)`),
those C macros expand and break compilation with errors.
In `PythonQtPythonInclude.h`, explicitly `#undef` the problematic <ctype.h> macros
(isalnum, isalpha, islower, isspace, isupper, tolower, toupper) after including Python
headers. This keeps macro pollution out of downstream C++ includes and lets the std:: functions/
overloads compile cleanly.
It fixes error like the following:
```
/usr/include/c++/4.2.1/bits/localefwd.h:57:21: error:
too many arguments provided to function-like macro invocation
isspace(_CharT, const locale&);
```
```
moc_PythonQtStdDecorators.cxx:152:25:
error: expected unqualified-id
case 4: _t->emit((*reinterpret_cast<
QObject*(*)>(_a[1])),(*reinterpret_cast< const
`
```
(cherry picked from commit commontk/PythonQt@4ce028d)
… macOS C++ builds CPython’s `pyport.h` defines `_PY_PORT_CTYPE_UTF8_ISSUE` on macOS to work around BSD libc ctype behavior in UTF-8 locales. Those ctype names can surface as macros and collide with libstdc++’s `<locale>` templated overloads (e.g., `std::isspace`), leading to compilation errors. Previously we unconditionally `#undef`’d several ctype macros. Restrict this to the affected environment by guarding with `_PY_PORT_CTYPE_UTF8_ISSUE` and `__cplusplus`. This keeps macOS C++ builds healthy while avoiding unnecessary macro tampering elsewhere. Adapted from Kitware/VTK@a4fa448099 ("Remove the toupper macro defined by Python.h.", 2015-11-12).
| // Avoid clashes with libstdc++ <locale> by undefining ctype macros | ||
| // that CPython may introduce on macOS when the UTF-8 ctype quirk is enabled. | ||
| // (_PY_PORT_CTYPE_UTF8_ISSUE is defined by CPython’s pyport.h; we apply these | ||
| // undefs only in C++ builds.) |
Contributor
There was a problem hiding this comment.
Interesting. Searching for this reveals a number of similar issues in CPython itself, which they seem to have resolved by using the macros from pyctype.h like Py_ISALPHA etc.
mrbean-bremen
approved these changes
Sep 4, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request addresses compilation issues on older macOS toolchains caused by ctype macros defined by
<Python.h>. The changes include:isalnum,isalpha,islower,isspace,isupper,tolower,toupper) after including Python headers, to avoid clashes with C++ standard library headers like<locale>._PY_PORT_CTYPE_UTF8_ISSUEand__cplusplusmacros.Note
For reference, those patches were developed in the context of the
commontk/PythonQtfork.Cherry picked from commits commontk/PythonQt@4ce028d