[PATCH] Deprecate libcrypt and don't build it by default.
Joseph Myers
joseph@codesourcery.com
Tue Aug 29 20:16:00 GMT 2017
On Tue, 29 Aug 2017, Zack Weinberg wrote:
> Back in June, Björn Esser proposed to add OpenBSD-compatible bcrypt
> support to our implementation of crypt(3), and I replied that it might
> actually make more sense to _remove_ libcrypt from glibc, freeing up
> libcrypt.so.1 and crypt.h to be provided by a separate project that
> could move faster. (For instance, libxcrypt:
> https://github.com/besser82/libxcrypt)
I don't believe libxcrypt's claim to be a binary-compatible replacement
for libcrypt.so.1. It looks to me like it uses symbol version GLIBC_2.0
unconditionally for the glibc symbols, when the actual base version
depends on the architecture / ABI for which glibc is built; GLIBC_2.0 is
only for a few architectures such as i386 with very longstanding ports.
(It could of course be taught to find the base version at configure time,
e.g. by checking the output of objdump -T on libc for a symbol such as abs
we can be confident won't get new symbol versions, though for that you
first need to locate the shared libc the compiler is linking against,
which is not completely trivial - "$CC $CFLAGS $CPPFLAGS
-print-file-name=libc.so" will give you the linker script, not the shared
library, and paths therein may be relative to a sysroot so you'd need to
process the linker script and combine with -print-sysroot output; "$CC
$CFLAGS $CPPFLAGS -print-file-name=libc.so.6" is incorrect on alpha where
it's libc.so.6.1.)
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list