This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Some C-API symbols (e.g. Py_FrozenMain) are not always exported on Unix
Type: Stage: resolved
Components: C API Versions: Python 3.11
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: kulikjak, miss-islington, petr.viktorin, shihai1991, vstinner
Priority: normal Keywords: patch

Created on 2021-05-14 16:58 by vstinner, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
reproduce.tar.gz vstinner, 2021-05-14 16:58
Pull Requests
URL Status Linked Edit
PR 26130 closed vstinner, 2021-05-14 17:05
PR 29148 closed miss-islington, 2021-10-22 08:12
PR 29876 closed shihai1991, 2021-12-01 09:20
PR 30556 merged vstinner, 2022-01-12 12:38
PR 30636 merged vstinner, 2022-01-17 13:03
Messages (17)
msg393675 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-05-14 16:58
When Python is built without --enable-shared, the "Py_FrozenMain" is not exported.

When Python is built with --enable-shared, the "Py_FrozenMain" is exported as expected.

I can reproduce the issue with attached reproduce.tar.gz example:

* build.sh exports "func1" symbol
* build_ar.sh doesn't export the "func1" symbol

The difference is that build.sh links directly two object files (.o) into a binary, whereas build_ar.sh creates a static library (.a) and then link the static library into a binary.

Python is always built with a static library (libpythonVERSION.a) which causes the issue.

A solution is to pass -Wl,--whole-archive option to the linker to export *all* symbols exported by all object files, and not only export symbols of the object files which are used.

I'm not sure why, but "Py_FrozenMain" is the *only* impacted symbol of the whole C API.

This issue was discovered by Petr Viktorin who works on the stable ABI:
https://mail.python.org/archives/list/capi-sig@python.org/thread/5QLI3NUP3OSGLCCIBAQOTX4GEJQBWJ6F/
msg393676 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-05-14 17:00
The "python" binary exports 1610 symbols. With the attached fix, it exports 1611 symbols (+1): "Py_FrozenMain" is also exported :-)
msg393693 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-05-14 21:14
The symbol is not exported on Windows neither. My PR 26126 ("Test Py_FrozenMain()") fails on Windows with:

"_testembed.obj : error LNK2001: unresolved external symbol __imp_Py_FrozenMain"

("__imp_" prefix is added by Windows DLL loader.)
msg404596 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-10-21 13:04
> I'm not sure why, but "Py_FrozenMain" is the *only* impacted symbol of the whole C API.

Apparently, on some platforms `PyModule_Create2` and `PyModule_FromDefAndSpec2` don't appear either.

Should I rename the issue to cover these as well?
msg404723 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-10-22 08:12
New changeset 276468dddb46c54980c782c09cdb53bd90755752 by Petr Viktorin in branch 'main':
bpo-43795: Add a test for Stable ABI symbol availability using ctypes (GH-26354)
https://github.com/python/cpython/commit/276468dddb46c54980c782c09cdb53bd90755752
msg404748 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-10-22 10:35
Repurposing this bug to track all symbols that don't appear in some configurations.

- `Py_FrozenMain` should be added to stable ABI when this is fixed. It was left out of the 3.10 stable ABI for only this reason. See discussion here: https://mail.python.org/archives/list/capi-sig@python.org/thread/5QLI3NUP3OSGLCCIBAQOTX4GEJQBWJ6F/

- `PyModule_Create2` and `PyModule_FromDefAndSpec2` are "temporarily" excluded from tests in `Tools/scripts/stable_abi.py`'s `gen_ctypes_test`, so that all the other symbols can get regression testing. When this issue is fixed, that special case should be removed.
msg406980 - (view) Author: Jakub Kulik (kulikjak) * Date: 2021-11-25 08:55
On Solaris (and most likely several other platforms), `PyThread_get_thread_native_id` is also not available.
msg410401 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-12 15:19
> On Solaris (and most likely several other platforms), `PyThread_get_thread_native_id` is also not available.

Oh, I added an explicit test for that in my PR 30556.

> `Py_FrozenMain` should be added to stable ABI

I suggest to first fix the issue (export the symbol), and then write a second PR to add it to the stable ABI.
msg410503 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-13 18:24
New changeset 6be848922bc0f4c632c255c39de82a45b6480286 by Victor Stinner in branch 'main':
bpo-44133: Link Python executable with object files (GH-30556)
https://github.com/python/cpython/commit/6be848922bc0f4c632c255c39de82a45b6480286
msg410504 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-13 18:27
> New changeset 6be848922bc0f4c632c255c39de82a45b6480286 by Victor Stinner in branch 'main':
> bpo-44133: Link Python executable with object files (GH-30556)

Sadly, Py_FrozenMain() is still missing on Windows. See:
https://github.com/python/cpython/pull/30556#issuecomment-1012032712

Until Windows also exports the symbol, I don't think that we can add the symbol to the stable ABI.

I prefer to not backport the change since it's always risky to break the build system on a stable branch.

If someone wants to fix the Windows build to also export Py_FrozenMain(), please open a new issue.

I consider that the initial issue is fixed, so I close the issue.
msg410756 - (view) Author: Jakub Kulik (kulikjak) * Date: 2022-01-17 10:40
>> On Solaris (and most likely several other platforms), `PyThread_get_thread_native_id` is also not available.

> Oh, I added an explicit test for that in my PR 30556.

Now it started failing on a different place:

======================================================================
FAIL: test_export_symbols (test.test_capi.CAPITest) (name='PyThread_get_thread_native_id')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/..../cpython-main/Lib/test/test_capi.py", line 662, in test_export_symbols
    self.assertTrue(hasattr(ctypes.pythonapi, name))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: False is not true

Looking at the test, is the expectation that all OSes must implement it since 3.11?
msg410757 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-17 11:22
Oh no, I expected that the new way to build Python would also export PyThread_get_thread_native_id() on Solaris. I reopen the issue.

Can you please specify your configure command? Can you check without Python if the symbol is exported or not? If you use --enable-shared, check in libpython, otherwise check in the "python" binary.
msg410762 - (view) Author: Jakub Kulik (kulikjak) * Date: 2022-01-17 11:47
Ah, sorry, I could have described the issue better. It's not a problem with exporting, PyThread_get_thread_native_id() isn't available on Solaris (and possibly other platforms) at all.

https://github.com/python/cpython/blob/main/Include/pythread.h#L28
https://github.com/python/cpython/blob/main/Python/thread_pthread.h#L329

The reason I didn't implement it yet is that Solaris doesn't expose anything like native thread id. We do have functions like `_lwp_self()` or `pthread_self()` or `thr_self()` but neither of them returns id where "value may be used to uniquely identify this particular thread system-wide". (I presume that means that no other thread of no other process running on a given system would return the same number - all these functions return single digit numbers so there is no way they are unique system wide).

If necessary, I guess that such a number can be created by masking pid and thread id together, but then there's a question of how it is supposed to be used (because OS would not understand it).
msg410776 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-17 13:03
> Ah, sorry, I could have described the issue better. It's not a problem with exporting, PyThread_get_thread_native_id() isn't available on Solaris (and possibly other platforms) at all.

Oh ok, it's a simple bug in my test. I wrote GH-30636 to fix it.
msg410787 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-17 13:49
New changeset 16901c0482734dbd389b09ca3edfcf3e22faeed7 by Victor Stinner in branch 'main':
bpo-44133: Skip PyThread_get_thread_native_id() if not available (GH-30636)
https://github.com/python/cpython/commit/16901c0482734dbd389b09ca3edfcf3e22faeed7
msg416378 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2022-03-30 15:55
> Ah, sorry, I could have described the issue better. It's not a problem with exporting, PyThread_get_thread_native_id() isn't available on Solaris (and possibly other platforms) at all.

Jakub, does this mean test_stable_abi_ctypes fails on Solaris?
Are there any other missing functions?
I opened bpo-47169 to improve the situation.
msg416475 - (view) Author: Jakub Kulik (kulikjak) * Date: 2022-04-01 08:55
Yes, it still does, and PyThread_get_thread_native_id is the only symbol missing.
History
Date User Action Args
2022-04-11 14:59:45adminsetgithub: 88299
2022-04-01 08:55:02kulikjaksetmessages: + msg416475
2022-03-30 15:55:23petr.viktorinsetmessages: + msg416378
2022-01-17 13:50:21vstinnersetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2022-01-17 13:49:31vstinnersetmessages: + msg410787
2022-01-17 13:03:55vstinnersetmessages: + msg410776
2022-01-17 13:03:25vstinnersetstage: resolved -> patch review
pull_requests: + pull_request28839
2022-01-17 11:47:39kulikjaksetmessages: + msg410762
2022-01-17 11:22:42vstinnersetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg410757
2022-01-17 10:40:39kulikjaksetmessages: + msg410756
2022-01-13 18:28:02vstinnersettitle: Some C-API symbols (e.g. Py_FrozenMain) are not always exported -> Some C-API symbols (e.g. Py_FrozenMain) are not always exported on Unix
2022-01-13 18:27:51vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg410504

stage: patch review -> resolved
2022-01-13 18:24:37vstinnersetmessages: + msg410503
2022-01-12 15:19:37vstinnersetmessages: + msg410401
2022-01-12 12:38:07vstinnersetpull_requests: + pull_request28757
2021-12-01 09:20:15shihai1991setnosy: + shihai1991
pull_requests: + pull_request28101
2021-11-25 08:55:51kulikjaksetnosy: + kulikjak
messages: + msg406980
2021-10-22 10:35:46petr.viktorinsetmessages: + msg404748
title: "Py_FrozenMain" symbol is not exported -> Some C-API symbols (e.g. Py_FrozenMain) are not always exported
2021-10-22 08:12:16miss-islingtonsetnosy: + miss-islington
pull_requests: + pull_request27425
2021-10-22 08:12:11petr.viktorinsetmessages: + msg404723
2021-10-21 13:04:00petr.viktorinsetnosy: + petr.viktorin
messages: + msg404596
2021-05-14 21:14:48vstinnersetmessages: + msg393693
2021-05-14 17:05:10vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request24769
2021-05-14 17:00:16vstinnersetmessages: + msg393676
2021-05-14 16:58:44vstinnercreate