Re: [PATCH] New configure option --disable-libcrypt.

[Zack Weinberg <zackw@panix.com>]

On Mon, Apr 16, 2018 at 11:10 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 04/16/2018 03:36 AM, Zack Weinberg wrote:
>>
>> diff --git a/elf/tst-linkall-static.c b/elf/tst-linkall-static.c
>> index e8df38f74e..0ffae7c723 100644
>> --- a/elf/tst-linkall-static.c
>> +++ b/elf/tst-linkall-static.c
>> @@ -18,7 +18,9 @@
>>     #include <math.h>
>>   #include <pthread.h>
>> +#if USE_CRYPT
>>   #include <crypt.h>
>> +#endif
>
> The #include should be indented.

Will fix.

>> +/* The X/Open Encryption Option Group may or may not be supported in
>> +   this release of the GNU C Library.  */
>> +#include <bits/unistd-crypt.h>
>
> Based on the Fedora experience, I wonder if it's not best to keep support
> _XOPEN_CRYPT unconditionally.  GCC still supports implicit function
> definitions by default and coerces the implied int return type to a pointer
> value.
...
> From a developer perspective, it would avoid a bit of hassle if we just said
> that if a distribution builds with --disable-libcrypt, it still needs to
> supply a compatible libcrypt with a definition of crypt and a default symbol
> version.
>
> With encrypt and setkey, the situation is less pronounced because these
> functions are obsolete, and we can produce link errors if developers use
> them.

Let me see if I understand what you have in mind:  In
--disable-libcrypt mode, we would preserve _XOPEN_CRYPT, with value 1,
and the prototype for crypt in unistd.h.  We would also preserve the
prototypes for encrypt and setkey, but maybe with
__attribute__((deprecated)).  We just wouldn't provide crypt.h or
libcrypt.  It's not a conformance violation for us to continue
defining _XOPEN_CRYPT as 1 because, as long as you get libcrypt from
_somewhere_, it will work at runtime.  Is that right?

I like this plan because it means the patch doesn't have to touch Makerules :)

zw

p.s. Maybe someone with the ability to file Austin Group defect
reports or interpretation requests or whatever they're called should
request the formal deprecation of encrypt and setkey?