python / python/cpython

Windows debug abi3t extensions autolink python316_d.lib instead of python316t_d.lib

オープン
#157,611 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

type-bug
主要言語
Python
スター
77.2k
フォーク
35.9k
PR マージ指標
PR 指標を取得中

説明

Bug report

Bug description:

On the current main branch, an MSVC-compatible debug extension that defines
Py_LIMITED_API and Py_TARGET_ABI3T can select the ordinary debug import
library instead of the free-threaded debug library.

The ordering in the public headers appears to cause the mismatch:

  1. PC/pyconfig.h selects the autolink library.
  2. Only later does Include/pyabi.h derive Py_GIL_DISABLED from
    Py_TARGET_ABI3T.

The debug autolink branch in PC/pyconfig.h currently checks only
Py_GIL_DISABLED. An abi3t extension identifies its target with
Py_TARGET_ABI3T, so it does not necessarily define Py_GIL_DISABLED before
including these headers.

I reproduced this by compiling a minimal Windows x86-64 COFF object with Clang
in MSVC-compatible target mode. The probe defines _DEBUG, Py_LIMITED_API,
and Py_TARGET_ABI3T=0x030f0000, then includes the two headers in their normal
order:

#include "PC/pyconfig.h"
#include "Include/pyabi.h"

#ifndef Py_GIL_DISABLED
#  error "Py_TARGET_ABI3T did not enable Py_GIL_DISABLED"
#endif

int cpython_abi3t_autolink_probe;

The resulting object's .drectve section contains:

/DEFAULTLIB:python316_d.lib

Defining Py_GIL_DISABLED explicitly before including the headers instead
produces:

/DEFAULTLIB:python316t_d.lib

The release abi3t case already selects python3t.lib; the mismatch is specific
to the versioned debug-library branch. The PCbuild naming also identifies
python316t_d.lib as the free-threaded debug import library.

A minimal possible fix is to recognize the ABI target at the point where the
autolink library is selected:

-#if defined(Py_GIL_DISABLED)
+#if defined(Py_GIL_DISABLED) || defined(Py_TARGET_ABI3T)

With that change, the original probe, without an explicit
Py_GIL_DISABLED, emits /DEFAULTLIB:python316t_d.lib.

This test inspects the Windows linker directive emitted by the public headers,
but I have not run a native Windows extension build. Could you confirm whether
Py_TARGET_ABI3T should select the free-threaded debug import library at this
earlier point? If so, I can prepare a pull request with this change, or adjust
it if changing the include/derivation order is preferred.

CPython versions tested on

CPython main.

Operating systems tested on

The reproducer was cross-compiled on Linux for the Windows x86-64 MSVC target.
Native Windows validation has not yet been performed -- as I do not have a windows machine.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs
  • gh-157623

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

PC/pyconfig.h の autolink 選択と Include/pyabi.h の ABI 導出から始めます。文書化された probe を再現するか、リンクされている PR gh-157623 を確認し、その後、Windows の debug abi3t ケースが、明示的な Py_GIL_DISABLED を必要とせずに free-threaded import-library directive を出力することを検証します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
c, python
領域
build-system, operating-systems
issue の種類
バグ
難易度
2/5
見積もり時間
1〜3時間
活発さ
停滞
明瞭さ
明確に書かれている
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。