Title: libpython should not be linked with libcrypt
Type: compile error Stage: resolved
Components: Build Versions: Python 3.11
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: floppymaster, thesamesam, vstinner
Priority: normal Keywords: patch

Created on 2021-10-11 18:11 by floppymaster, last changed 2021-10-12 02:58 by thesamesam. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 28881 merged floppymaster, 2021-10-11 19:02
Messages (3)
msg403663 - (view) Author: Mike Gilbert (floppymaster) * Date: 2021-10-11 18:11
In, 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, 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)

#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. 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.
msg403701 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-10-11 23:24
New changeset be21706f3760bec8bd11f85ce02ed6792b07f51f by Mike Gilbert in branch 'main':
bpo-45433: Do not link libpython against libcrypt (GH-28881)
msg403702 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-10-11 23:24
Nicely spotted, thanks for the fix!

I prefer to not backport to avoid any risk of regression. In my experience, the build system is fragile.
Date User Action Args
2021-10-12 02:58:00thesamesamsetnosy: + thesamesam
2021-10-11 23:24:50vstinnersetstatus: open -> closed
versions: - Python 3.7, Python 3.8, Python 3.9, Python 3.10
messages: + msg403702

components: + Build, - C API
resolution: fixed
stage: patch review -> resolved
2021-10-11 23:24:11vstinnersetnosy: + vstinner
messages: + msg403701
2021-10-11 19:02:14floppymastersetkeywords: + patch
stage: patch review
pull_requests: + pull_request27176
2021-10-11 18:11:14floppymastercreate