This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't add nis subdir for new architectures
- From: Zack Weinberg <zackw at panix dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 4 Jul 2018 11:53:58 -0400
- Subject: Re: [PATCH] Don't add nis subdir for new architectures
- References: <mvmefgj81b5.fsf@suse.de>
On Wed, Jul 4, 2018 at 11:31 AM, Andreas Schwab <schwab@suse.de> wrote:
> For future architectures, sysdeps/unix/inet no longer implies building the
> nis subdirectory, and --enable-obsolete-nsl is ignored.
This change appears to be technically correct for the existing Linux
ports. I don't have enough context to assess whether it might have
negative consequences, but I support it in principle.
I have two minor concerns:
1) Should the nis directory continue to be built by default for the
existing Hurd port (ix86-gnu)? I don't think that port has a stable
ABI yet, so perhaps not, but I'd like to hear that from Samuel.
2) The text added to install.texi / INSTALL is unclear:
> --- a/manual/install.texi
> +++ b/manual/install.texi
> @@ -229,6 +229,8 @@ compatibility and the NSS modules libnss_compat, libnss_nis and
> libnss_nisplus are not built at all.
> Use this option to enable libnsl with all depending NSS modules and
> header files.
> +This option has no effect on architectures that were added after the
> +2.27 release.
as it could mean either that --enable-obsolete-nsl mode cannot be
turned *on* for new architectures, or that it cannot be turned *off*.
I suggest
Architectures added after the 2.27 release will not even build libnsl as a
compatibility library; this option has no effect on those architectures.
zw