[New-bugs-announce] [issue45433] libpython should not be linked with libcrypt
Mike Gilbert
report at bugs.python.org
Mon Oct 11 14:11:14 EDT 2021
New submission from Mike Gilbert <floppymaster at 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 <report at bugs.python.org>
<https://bugs.python.org/issue45433>
_______________________________________
More information about the New-bugs-announce
mailing list