From ae06748508feb75fbfbb28ce473d6bff2c5314f0 Mon Sep 17 00:00:00 2001 From: vasilito Date: Tue, 4 Aug 2026 22:24:45 +0300 Subject: [PATCH] install: ship empty libcrypt.a and libutil.a compat archives relibc implements crypt/crypt_r inside libc itself, but build systems still pass -lcrypt because that is where glibc puts it. The link then fails even though the symbols are present: ld: cannot find -lcrypt: No such file or directory (KDE plasma-workspace kcms/users). nm confirms libc.a exports crypt and crypt_r. Ships empty archives so -lcrypt and -lutil resolve and the symbols come from libc -- the same approach musl takes, and the same pattern this Makefile already uses for libdl, libpthread and librt. --- Makefile | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 4534cf829f..9331b5dec5 100644 --- a/Makefile +++ b/Makefile @@ -97,10 +97,18 @@ ifeq ($(USE_RUST_LIBM),) else $(AR) -rcs "$(DESTDIR)/lib/libm.a" endif - # Empty libraries for dl, pthread, and rt + # Empty compatibility archives. relibc implements these APIs inside libc + # itself, but build systems still pass -ldl/-lpthread/-lrt/-lcrypt/-lutil + # because that is where glibc puts them. Shipping empty archives lets the + # link resolve and the symbols come from libc -- the same approach musl + # takes. Without libcrypt.a, KDE's kcm_users fails with + # ld: cannot find -lcrypt: No such file or directory + # even though libc.a exports both crypt and crypt_r. $(AR) -rcs "$(DESTDIR)/lib/libdl.a" $(AR) -rcs "$(DESTDIR)/lib/libpthread.a" $(AR) -rcs "$(DESTDIR)/lib/librt.a" + $(AR) -rcs "$(DESTDIR)/lib/libcrypt.a" + $(AR) -rcs "$(DESTDIR)/lib/libutil.a" install-tests: tests $(MAKE) -C tests