On 19 May 2021, at 12:15, Victor Stinner <vstinner@python.org> wrote:
On Fri, May 14, 2021 at 7:05 PM Victor Stinner <vstinner@python.org> wrote:
Hi Petr,
I reproduced the issue with Python is built without --enable-shared.
But when Python is built with --enable-shared, Py_FrozenMain() is exported as expected!
I created https://bugs.python.org/issue44133 and https://github.com/python/cpython/pull/26130 to fix the issue.
This issue is not specific to the "Py_FrozenMain" symbol. *Any* symbol can miss depending on how Python was built and where the function lives. If you move an exported function to a new C function and the function is not used directly by Python, the function is no longer exported.
Do you mean “new C file” instead of “new C function”? Because all C compilers I’ve used so far default to including whose object files when a program uses at least one symbol from that object file. That’s why Py_FrozenMain() is currently the only missing symbol, the rest of the core has sufficiently large source code files to ensure all of them will be included. The issue could crop up for other symbols if, for example, functions that are included only for backward compatibility were to be moved to separate files.
That said, newer version of at least the GCC stack strip unused symbols when using the right compiler invocation (“-ffunction-sections” and related options).
This bug is a major issue, because C extensions are no longer linked to libpython since Python 3.8. Python must export all symbols that it pretends to export, especially if it built without libpython dynamic library (libpythonXY.so).
It has been a problem longer than that, if I recall correctly framework builds on macOS have never linked extensions to libpython. That said, as I wrote above this is currently not that large of an issue due to the way the code is structured and the way linkers work.
Ronald
—
Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/