New submission from Mike Gilbert <floppymas...@gmail.com>:
In https://bugs.python.org/issue44751, crypt.h was removed from Python.h. This would imply that libpython is not meant to expose any crypt-related symbols. In fact, it looks like libpython does not use crypt() or crypt_r() at all. These are only used by cryptmodule. In configure.ac, we have this this logic to determine if crypt_r() is available: ``` # We search for both crypt and crypt_r as one or the other may be defined # This gets us our -lcrypt in LIBS when required on the target platform. AC_SEARCH_LIBS(crypt, crypt) AC_SEARCH_LIBS(crypt_r, crypt) AC_CHECK_FUNC(crypt_r, AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #define _GNU_SOURCE /* Required for crypt_r()'s prototype in glibc. */ #include <crypt.h> ]], [[ struct crypt_data d; char *r = crypt_r("", "", &d); ]])], [AC_DEFINE(HAVE_CRYPT_R, 1, [Define if you have the crypt_r() function.])], []) ) ``` The AC_SEARCH_LIBS macro adds "-lcrypt" to LIBS, and this gets passed down to the link command for libpython. This is probably not intentional. The HAVE_CRYPT_R value is used in _cryptmodule.c. setup.py performs its own check for libcrypt when building the module. I think the value of LIBS should be saved before the AC_SEARCH_LIBS calls and restored after the AC_CHECK_FUNC call. I have tested this locally on Gentoo Linux, and it seems to work fine. I will work on a pull request. ---------- components: C API messages: 403663 nosy: floppymaster priority: normal severity: normal status: open title: libpython should not be linked with libcrypt type: compile error versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45433> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
