Re: [PATCH] Deprecate libcrypt and don't build it by default.

[Joseph Myers <joseph at codesourcery dot com>]

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