On 18 May 2021, at 15:08, Petr Viktorin <encukou@gmail.com> wrote:
On 18. 05. 21 14:20, Marc-Andre Lemburg wrote:
On 18.05.2021 13:57, Petr Viktorin wrote:
On 18. 05. 21 13:50, Marc-Andre Lemburg wrote:
On 18.05.2021 13:39, Petr Viktorin wrote:
On 18. 05. 21 13:26, Marc-Andre Lemburg wrote:
On 18.05.2021 13:02, Ronald Oussoren wrote: >> If you are embedding a Python with frozen modules, you will need to >> call the Py_FrozenMain() API from your application's main() (or other >> entry point within your application). >> >> Removing the export will break such applications. Removing the API >> from the stable ABI makes it impossible to use the stable ABI from >> such applications. >> >> Is that intended ? Perhaps I'm missing something. > > The discussion is about having a Py_FrozenMain() ABI in a statically linked > python executable. That executable cannot be used to create a frozen > application > because, as you say, those need a custom main function that calls > Py_FrozenMain() and should therefore link to libpython (either dynamically or > statically).
I lost you there :-)
My understanding is that the ABI defines the exports of libpythonX.X.a and an executable using frozen modules would have to link against this lib. If you remove Py_FrozenMain() from the lib, this no longer works. If you remove Py_FrozenMain() from the stable ABI, your executable would not be able to reference it (when using the stable ABI).
No, libpython is not limited to the stable ABI. python3.dll is, but that's a shared library.
Hm, I just found Py_ENABLE_SHARED. That sounds like the feature flag with which Py_FrozenMain should be defined/exported.
Just to be clear: you can build the Python lib as a shared lib on Unix as well.
Sure, that's how I use Python :) But on Unix, that shared library exports all symbols, not just those in the Stable ABI.
Right, but if you want to use the stable ABI, the compiler would not see the needed Py_FrozenMain() definition to link against -- if you remove it from the stable ABI. So overall, it's probably not such a good idea to remove that particular API from the stable ABI list.
Yeah, the more I dig, the more I'm convinced that Py_FrozenMain should be on the list.
That means it should always be available, though -- even in static builds.
I don’t understand why this is so. Py_FrozenMain must only be present in the dynamic library, including the stable ABI on Windows (because AFAIK it already is). In a staticly linked python executable the symbol is not necessary because it will (and can) never be used.
And the option to include it is compiler-specific:
- gcc needs --whole-archive
- clang seems to need -all_load
- not sure about MSVC
That works, but a tool-independent way to force inclusion is to use the symbol from a source file that is already included. Or alternatively explicitly link the object file containing Py_FrozenMain() into the executable (for static builds).
Ronald —
Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/