When building with recent version of gcc/clang (15/22), the position of the Python headers in the source files can interfere with previously defined macros, such as _POSIX_C_SOURCE. The Python official documentation states that for extensions Python headers should come before any system headers, with the following guideline (copied verbatim)
Note
Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included.
It is recommended to always define PY_SSIZE_T_CLEAN before including Python.h. See [Parsing arguments and building values](https://docs.python.org/3/c-api/arg.html#arg-parsing) for a description of this macro.
Through the codebase, we treat external package headers (like Python) as an expected follow behind system headers, which raises warnings such as
/usr/include/python3.14/pyconfig.h:2007:9: error: '_POSIX_C_SOURCE' macro redefined [-Werror,-Wmacro-redefined]
2007 | #define _POSIX_C_SOURCE 200809L
| ^
/usr/include/features.h:319:10: note: previous definition is here
319 | # define _POSIX_C_SOURCE 202405L
| ^
on newer systems. With warnings-as-errors enabled by default, this yields a build failure for any modules making use of such headers for extensions (such as anything nanobind related).
A quick swap of header positions shows this warning as resolved, but will be reintroduced following the clang-format rules applied to headers in the code-base. This will require an update to the rules as an exception for Python headers (both CPython and nanobind) to appear before any system headers on the given platform.
When building with recent version of gcc/clang (15/22), the position of the Python headers in the source files can interfere with previously defined macros, such as
_POSIX_C_SOURCE. The Python official documentation states that for extensions Python headers should come before any system headers, with the following guideline (copied verbatim)Through the codebase, we treat external package headers (like Python) as an expected follow behind system headers, which raises warnings such as
on newer systems. With warnings-as-errors enabled by default, this yields a build failure for any modules making use of such headers for extensions (such as anything nanobind related).
A quick swap of header positions shows this warning as resolved, but will be reintroduced following the clang-format rules applied to headers in the code-base. This will require an update to the rules as an exception for Python headers (both CPython and nanobind) to appear before any system headers on the given platform.