This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Deprecate libcrypt and don't build it by default.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: <libc-alpha at sourceware dot org>, <bjoern dot esser at gmail dot com>, <fweimer at redhat dot com>
- Date: Tue, 29 Aug 2017 20:16:21 +0000
- Subject: Re: [PATCH] Deprecate libcrypt and don't build it by default.
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
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:
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
Joseph S. Myers