Python.h conflicts with stdlib.h if included after that
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug report
Bug description:
Issue: Inconsistent _POSIX_C_SOURCE definition causes compilation errors when Python.h is included after system headers
Environment:
- Fedora 44
- CPython 3.14 (distro-provided packages)
- Go 1.26 with CGo
Description:
When Python.h is included after system headers such as stdlib.h, a compilation error occurs due to conflicting definitions of the _POSIX_C_SOURCE macro. The conflict arises because:
Python.hindirectly defines_POSIX_C_SOURCEvia its inclusion ofpyconfig-64.h(located at/usr/include/python3.14/pyconfig-64.h)- System headers like
stdlib.halso define_POSIX_C_SOURCEvia their inclusion of/usr/include/features.h - The two definitions differ, triggering a compiler diagnostic
Context:
While the official CPython documentation recommends including Python.h before any other headers, this is not always feasible. In my specific use case, I'm using the libpython3.so shared library from Go via CGo. The CGo toolchain automatically generates a C helper file that puts #include <stdlib.h> before any user-provided code, making it impossible to adhere to the "include Python.h first" recommendation.
Current workaround:
I'm currently using #undef _POSIX_C_SOURCE immediately before including Python.h:
#undef _POSIX_C_SOURCE
#include <Python.h>
However, this approach is fragile and potentially unsafe, as it may cause system headers to be compiled with different _POSIX_C_SOURCE values across translation units, leading to subtle ABI mismatches or undefined behavior.
Proposed fix:
Modify the generated pyconfig-*.h files to guard the _POSIX_C_SOURCE definition with #ifndef/#endif preprocessor directives, similar to how other feature test macros are often handled:
#ifndef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 200809L /* or whatever version is currently used */
#endif
This change would make the definition idempotent and prevent compilation errors regardless of include order, while maintaining the intended feature test macro settings.
Impact:
This issue affects any project that:
- Uses CPython's C API
- Cannot control the include order of system headers (e.g., via CGo, SWIG, or other binding generators)
- Builds on platforms where
_POSIX_C_SOURCEis defined by system headers
Cc: @sobolevn
CPython versions tested on:
3.14
Operating systems tested on:
Linux
Linked PRs
- gh-155343
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、issue にリンクされている PR gh-155343 と、_POSIX_C_SOURCE の定義に関係する生成済みの pyconfig-*.h ファイルを確認します。Python.h を stdlib.h の後にインクルードした場合の動作を比較し、続いて報告されている Fedora 44 と CPython 3.14 のセットアップを使ってコンパイルエラーを再現します。include-order のケースで、feature-test の設定に一貫性がない状態を導入することなく、競合するマクロ診断が発生しなくなれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- c, python
- 領域
- build-system
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100