This makes it impossible to build libcrypt, so add a NEWS entry for
the removal at this point, and remove the prototype for crypt() from
unistd.h.  Also removed at this point are a handful of references to
libcrypt in other directories (notably elf/, conform/, and SPARCv9
sysdep Makefiles) and in maintainer-facing scripts and docs.

stdio-common/Versions says that __snprintf is exported as
GLIBC_PRIVATE because libcrypt uses it.  I doubt that was the only
ancillary library using that symbol, but I don't know how to find
other uses, so I left the export in place; it can always be removed
later.

There are a few files of test data that mention the crypt directory
and/or its contents, e.g. benchtests/strcoll-inputs/filelist#en_US.UTF-8.
As best I can tell, the intent of these is just to have a big pile of
strings and it doesn't matter whether the named files exist, so I
haven't altered them.

The actual code, and the remainder of the documentation, will be
deleted in subsequent patches.

(I seem to have a slightly different version of autoconf than the one
that was last used to regenerate the top-level configure script.  If
that's a problem, let me know.)

Commit 78ceef25d64efeeb6067d1cb282a00466e637e2a ("configure: Remove
--enable-all-warnings option") removed it due to a missing +.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

The option is not activelly tested and has bitrotten, to fix it
would require a lot of work and multiple fixes.  A better option
would to evaluate each option and enable the warning if it makes
sense.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

Add --enable-fortify-source option.

It is now possible to enable fortification through a configure option.
The level may be given as parameter, if none is provided, the configure
script will determine what is the highest level possible that can be set
considering GCC built-ins availability and set it.
If level is explicitly set to 3, configure checks if the compiler
supports the built-in function necessary for it or raise an error if it
isn't.

If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is
forcibly undefined (and therefore disabled).

The result of the configure checks are new variables, ${fortify_source}
and ${no_fortify_source} that can be used to appropriately populate
CFLAGS.

A dedicated patch will follow to make use of this variable in Makefiles
when necessary.

Updated NEWS and INSTALL.

Adding dedicated x86_64 variant that enables the configuration.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

And make always supported.  The configure option was added on glibc 2.25
and some features require it (such as hwcap mask, huge pages support, and
lock elisition tuning).  It also simplifies the build permutations.

Changes from v1:
 * Remove glibc.rtld.dynamic_sort changes, it is orthogonal and needs
   more discussion.
 * Cleanup more code.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

And remove the usage of glibc reserved names.
Reviewed-by: DJ Delorie <dj@redhat.com>

The library was removed by 65ccd641ba.

make-4.4 will add long flags to MAKEFLAGS variable:

    * WARNING: Backward-incompatibility!
      Previously only simple (one-letter) options were added to the MAKEFLAGS
      variable that was visible while parsing makefiles.  Now, all options
      are available in MAKEFLAGS.

This causes locale builds to fail when long options are used:

    $ make --shuffle
    ...
    make  -C localedata install-locales
    make: invalid shuffle mode: '1662724426r'

The change fixes it by passing eash option via whitespace and dashes.
That way option is appended to both single-word form and whitespace
separated form.

While at it fixed --silent mode detection in $(MAKEFLAGS) by filtering
out --long-options. Otherwise options like --shuffle flag enable silent
mode unintentionally. $(silent-make) variable consolidates the checks.

Resolves: BZ# 29564

CC: Paul Smith <psmith@gnu.org>
CC: Siddhesh Poyarekar <siddhesh@gotplt.org>
Signed-off-by: Sergei Trofimovich <slyich@gmail.com>
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

We should default to the larger code model, in order to support
larger applications built with -static -pie.  This should be
consistent with pic-ccflag, which defaults to -fPIC.

Remove the now redundant override from sysdeps/sparc/Makefile.
Note that -fno-pie and -fno-PIE have the same effect.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>