Re: [PATCH v2 0/2] Add experimental option --enable-py-limited-api

[Matthieu Longo <matthieu.longo@arm.com>]

On 2025-10-14 18:22, Eli Zaretskii wrote:
>> From: Matthieu Longo <matthieu.longo@arm.com>
>> CC: Tom Tromey <tom@tromey.com>, Andrew Burgess <aburgess@redhat.com>,
>>   Matthieu Longo <matthieu.longo@arm.com>
>> Date: Tue, 14 Oct 2025 17:44:56 +0100
>>
>> This patch series introduces an experimental build option, '--enable-py-limited-api', which allows GDB to be compiled against the Python 3 stable C API.
>>
>> As explained in [1] and [2], using the stable API would make it possible to build GDB against one version of Python 3, while still allowing it to run with other versions available on the user's system.
>>
>> The migration to the stable API can be done incrementally. These patches do not attempt to port the entire codebase at once. Instead, they provide a development mode where contributors can experiment with the limited API and progressively fix incompatibilities. By default, this option is disabled (--enable-py-limited-api=no).
>>
>> The series contains two patches:
>> - Update the Python conftest to avoid use of unstable API calls, ensuring compatibility with the limited API.
>> - Introduce the --enable-py-limited-api option in GDB's configure.
>>
>> Tested with Python 3.4 and 3.13.
>>
>> Diff against revision 1:
>> - addressed comments of Tom Tromey regarding code formatting, and removal of config.h
> 
> Thanks.  Should this be in NEWS?
> 

For now, this patch only provides the first brick of a migration of GDB 
to the Python limited API, i.e. an experimentation flag to enable 
developers who want to contribute to the migration to rebuild GDB easily 
with the limited API enabled.
There remains much to be done. Consequently, I don't think that there is 
much to write in NEWS today.

> Also, I'm guessing that this change will not allow to run the MinGW
> build of GDB with versions of Python other than the one against which
> GDB was compiled, because AFAIK linking against shared libraries on
> Windows records that library in the executable, and GDB will therefore
> refuse to run when that DLL cannot be found.  So, for example, if GDB
> was linked against python34.dll, it will insist on finding it when
> Windows loads the executable, and if not found, will not run.
> 
> If we want this to work on Windows, we need to load the Python DLL at
> runtime, using the likes of dlopen, and then manually import the APIs
> we need using dladdr.  Which AFAIU, this patch doesn't do.
> 

This issue is discussed in [2], section "Shared library naming issue in 
CPython" (see cover letter). The proposed approach would rely on 
python3.dll, but it can be reviewed later on if it becomes a blocker.

> Apologies if I'm missing something, and thus make no sense.

No worry.

Matthieu