This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Don't add nis subdir for new architectures


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]