Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2021-10-11.23:24:50.373>created_at=<Date2021-10-11.18:11:14.569>labels= ['build', '3.11']
title='libpython should not be linked with libcrypt'updated_at=<Date2021-10-12.02:58:00.239>user='https://github.com/floppym'
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.
#define _GNU_SOURCE /* Required for crypt_r()'s prototype in glibc. */
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.