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.
Whether you statically or dynamically link your executable against the lib does not really matter.
Just to clarify: the executable will not be using the standard Python main() entry point.
Note that freeze.py works in exactly this way. It defines its own main(), which then calls Py_FrozenMain(). The frozen.o then gets linked statically at libpythonX.X.a and the set of frozen modules.