There is an updated pull request by oreo639 against master on the void-packages repository https://github.com/oreo639/void-packages glibc https://github.com/void-linux/void-packages/pull/45501 [RFC] glibc: update to 2.38. #### Testing the changes - I tested the changes in this PR: **briefly** The following packages must be removed from the repo before merging this PR: - [ ] php8.0-apache-8.0.29_1: libcrypt.so.1 (https://repo-default.voidlinux.org/current) - [ ] php8.0-embed-8.0.29_1: libcrypt.so.1 (https://repo-default.voidlinux.org/current) - [ ] burp-client-1.4.40_12: libcrypt.so.1 (https://repo-default.voidlinux.org/current) - [ ] user-manager-5.19.5_1: libcrypt.so.1 (https://repo-default.voidlinux.org/current) [ci skip] https://sourceware.org/glibc/wiki/Release/2.38 glibc 2.38 disables libcrypt by default with a recommendation for distros to switch to [libxcrypt](https://github.com/besser82/libxcrypt) (as they intend to remove it entirely). libxcrypt can be built as either libcrypt.so.1 or libcrypt.so.2. Debian and SUSE only build libcrypt.so.1. Arch Linux and Fedora build libcrypt.so.2 along with a libxcrypt-compat package. The rationale for that decision is explained here: https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt https://fedoraproject.org/wiki/Changes/libcrypt_so_1_Let_encrypt_encrypt_r_setkey_setkey_r_and_fcrypt_return_ENOSYS_instead_of_performing_any_real_operation My inclination is to build libcrypt.so.2 with a libxcrypt-compat package without enosys but I am open to handling it differently. Keep in mind that packages compiled against libxcrypt's libcrypt.so.1 will not run with glibc's libcrypt.so.1 (but applications compiled with glibc's libcrypt.so.1 will run with libxcrypt's libcrypt.so.1). You can get the packages using libcrypt using `xbps-query -Rs libcrypt.so -p shlib-requires`. A patch file from https://github.com/void-linux/void-packages/pull/45501.patch is attached