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.

Author vstinner
Recipients doko, hroncok, lukasz.langa, ned.deily, swt2c, vstinner
Date 2019-05-22.13:58:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I mark this issue as a release blocker: bpo-21536 basically broke the compilation of all applications which embed Python. IMHO this issue is the best solution to fix it.

> I don't understand the need for this.

Oh. Let me explain this issue differently. There are two use cases for libpython:

* Build a C extension and load it in Python: use case called "pyext" by waf
* Embed Python into an application: use case called "pyembed" by waf

My bpo-21536 broke waf "pyembed" which fails to detect Python. waf "pyembed" creates a C program which calls Py_Initialize(), but the linker fails to locate Py_Initialize() symbol. To embed Python into an application, we really need to link the application to libpython: we need -lpython3.8.

In Python 3.7, "pyext" and "pyembed" use cases were covered both by default "python3.7-config --libs" and "pkg-config python3.7 --libs" configuration.

In Python 3.8, we now have to distinguish both use cases and provide *different* configuration depending if binary must be linked to libpython or not.

More info about waf breakage in my waf bug report:

FYI the waf breakage was discovered by trying to build libtdb on Fedora Rawhide with Python 3.8a4, it's a dependency of Samba which embeds Python:
Date User Action Args
2019-05-22 13:58:06vstinnersetrecipients: + vstinner, doko, ned.deily, lukasz.langa, hroncok, swt2c
2019-05-22 13:58:06vstinnersetmessageid: <>
2019-05-22 13:58:06vstinnerlinkissue36721 messages
2019-05-22 13:58:05vstinnercreate