This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] deprecate libnsl (Version 4)
On Thu, Feb 23, 2017 at 10:25 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> On Thu, Feb 23, Zack Weinberg wrote:
>
>> There are a lot of configure scripts out there that do
>> AC_CHECK_LIB([nsl], [gethostbyname]). Yes, that should be
>> AC_SEARCH_LIBS, the Autoconf manual even says so these days, but some
>> people are still using autoconf 2.13, so. Would you please verify
>> that an autoconf script with AC_CHECK_LIB([nsl], [gethostbyname]) in
>> it does _not_ fail when run against a glibc with this modification,
>> and the generated makefile does _not_ try to link -lnsl?
>
> Depends on what you understand under "fail":
>
> checking for gethostbyname in -lnsl... no
> checking that generated files are newer than configure... done
> configure: creating ./config.status
>
> And of course does the Makefile not try in this case to link against
> libnsl, while with libnsl, it will link against libnsl even if not
> needed. No change compared to today.
That should be good enough. I was worried that the configure script
would either error out, or would put -lnsl in $(LIBS) causing a
subsequent link to fail.
A configure script that thinks it doesn't have gethostbyname at all,
just because it isn't in -lnsl, was broken already.
>> The NEWS entry should explain which programs are likely to need your
>> libnsl replacement. It's my impression that the answer is "almost
>> none", but it's important to be reassuring here.
>
> There is no change in which applications needs libnsl or not compared
> to today with glibc.
Yes, but a randomly selected reader of NEWS (e.g. me) doesn't know
which applications those are. A one- or two-sentence explanation of
which applications do need libnsl would be helpful. ("Most
applications do not need libnsl. With the GNU C Library, it has only
ever been necessary for applications that do X, Y, or Z." I don't know
what X, Y or Z are.)
zw