STINNER Victor <vstin...@redhat.com> added the comment:
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: https://gitlab.com/ita1024/waf/issues/2239 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: https://bugzilla.redhat.com/show_bug.cgi?id=1711638 ---------- nosy: +lukasz.langa priority: normal -> release blocker _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
