Update from gnulib

This incorporates:
2018-08-05 Fix link error regarding 'rpl_environ'
* build-aux/config.guess, lib/unistd.in.h, lib/warn-on-use.h:
* m4/extern-inline.m4: Copy from Gnulib.

4 files changed, 61 insertions, 27 deletions

diff --git a/build-aux/config.guess b/build-aux/config.guess
index ba6af63cc44..d4fb3213ec7 100755
--- a/build-aux/config.guess
+++ b/build-aux/config.guess
@@ -2,7 +2,7 @@
 # Attempt to guess a canonical system name.
 #   Copyright 1992-2018 Free Software Foundation, Inc.
 
-timestamp='2018-07-18'
+timestamp='2018-08-02'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -126,7 +126,7 @@ set_cc_for_build() {
 
 # This is needed to find uname on a Pyramid OSx when run in the BSD universe.
 # (ghazi@noc.rutgers.edu 1994-08-24)
-if (test -f /.attbin/uname) >/dev/null 2>&1 ; then
+if test -f /.attbin/uname ; then
         PATH=$PATH:/.attbin ; export PATH
 fi
 
diff --git a/lib/unistd.in.h b/lib/unistd.in.h
index b6a348f5297..55bbb6ca3b7 100644
--- a/lib/unistd.in.h
+++ b/lib/unistd.in.h
@@ -432,12 +432,12 @@ extern char **environ;
 #elif defined GNULIB_POSIXCHECK
 # if HAVE_RAW_DECL_ENVIRON
 _GL_UNISTD_INLINE char ***
+_GL_WARN_ON_USE_ATTRIBUTE ("environ is unportable - "
+                           "use gnulib module environ for portability")
 rpl_environ (void)
 {
   return &environ;
 }
-_GL_WARN_ON_USE (rpl_environ, "environ is unportable - "
-                 "use gnulib module environ for portability");
 #  undef environ
 #  define environ (*rpl_environ ())
 # endif
diff --git a/lib/warn-on-use.h b/lib/warn-on-use.h
index e76c38427d5..72d67cc2348 100644
--- a/lib/warn-on-use.h
+++ b/lib/warn-on-use.h
@@ -20,23 +20,32 @@
    supported by the compiler.  If the compiler does not support this
    feature, the macro expands to an unused extern declaration.
 
-   This macro is useful for marking a function as a potential
+   _GL_WARN_ON_USE_ATTRIBUTE ("literal string") expands to the
+   attribute used in _GL_WARN_ON_USE.  If the compiler does not support
+   this feature, it expands to empty.
+
+   These macros are useful for marking a function as a potential
    portability trap, with the intent that "literal string" include
    instructions on the replacement function that should be used
-   instead.  However, one of the reasons that a function is a
-   portability trap is if it has the wrong signature.  Declaring
-   FUNCTION with a different signature in C is a compilation error, so
-   this macro must use the same type as any existing declaration so
-   that programs that avoid the problematic FUNCTION do not fail to
-   compile merely because they included a header that poisoned the
-   function.  But this implies that _GL_WARN_ON_USE is only safe to
-   use if FUNCTION is known to already have a declaration.  Use of
-   this macro implies that there must not be any other macro hiding
-   the declaration of FUNCTION; but undefining FUNCTION first is part
-   of the poisoning process anyway (although for symbols that are
-   provided only via a macro, the result is a compilation error rather
-   than a warning containing "literal string").  Also note that in
-   C++, it is only safe to use if FUNCTION has no overloads.
+   instead.
+   _GL_WARN_ON_USE is for functions with 'extern' linkage.
+   _GL_WARN_ON_USE_ATTRIBUTE is for functions with 'static' or 'inline'
+   linkage.
+
+   However, one of the reasons that a function is a portability trap is
+   if it has the wrong signature.  Declaring FUNCTION with a different
+   signature in C is a compilation error, so this macro must use the
+   same type as any existing declaration so that programs that avoid
+   the problematic FUNCTION do not fail to compile merely because they
+   included a header that poisoned the function.  But this implies that
+   _GL_WARN_ON_USE is only safe to use if FUNCTION is known to already
+   have a declaration.  Use of this macro implies that there must not
+   be any other macro hiding the declaration of FUNCTION; but
+   undefining FUNCTION first is part of the poisoning process anyway
+   (although for symbols that are provided only via a macro, the result
+   is a compilation error rather than a warning containing
+   "literal string").  Also note that in C++, it is only safe to use if
+   FUNCTION has no overloads.
 
    For an example, it is possible to poison 'getline' by:
    - adding a call to gl_WARN_ON_USE_PREPARE([[#include <stdio.h>]],
@@ -54,12 +63,21 @@
    (less common usage, like &environ, will cause a compilation error
    rather than issue the nice warning, but the end result of informing
    the developer about their portability problem is still achieved):
-   #if HAVE_RAW_DECL_ENVIRON
-   static char ***rpl_environ (void) { return &environ; }
-   _GL_WARN_ON_USE (rpl_environ, "environ is not always properly declared");
-   # undef environ
-   # define environ (*rpl_environ ())
-   #endif
+     #if HAVE_RAW_DECL_ENVIRON
+     static char ***
+     rpl_environ (void) { return &environ; }
+     _GL_WARN_ON_USE (rpl_environ, "environ is not always properly declared");
+     # undef environ
+     # define environ (*rpl_environ ())
+     #endif
+   or better (avoiding contradictory use of 'static' and 'extern'):
+     #if HAVE_RAW_DECL_ENVIRON
+     static char ***
+     _GL_WARN_ON_USE_ATTRIBUTE ("environ is not always properly declared")
+     rpl_environ (void) { return &environ; }
+     # undef environ
+     # define environ (*rpl_environ ())
+     #endif
    */
 #ifndef _GL_WARN_ON_USE
 
@@ -67,13 +85,17 @@
 /* A compiler attribute is available in gcc versions 4.3.0 and later.  */
 #  define _GL_WARN_ON_USE(function, message) \
 extern __typeof__ (function) function __attribute__ ((__warning__ (message)))
+#  define _GL_WARN_ON_USE_ATTRIBUTE(message) \
+  __attribute__ ((__warning__ (message)))
 # elif __GNUC__ >= 3 && GNULIB_STRICT_CHECKING
 /* Verify the existence of the function.  */
 #  define _GL_WARN_ON_USE(function, message) \
 extern __typeof__ (function) function
+#  define _GL_WARN_ON_USE_ATTRIBUTE(message)
 # else /* Unsupported.  */
 #  define _GL_WARN_ON_USE(function, message) \
 _GL_WARN_EXTERN_C int _gl_warn_on_use
+#  define _GL_WARN_ON_USE_ATTRIBUTE(message)
 # endif
 #endif
 
diff --git a/m4/extern-inline.m4 b/m4/extern-inline.m4
index da8a2cc01c7..3661cbda5ed 100644
--- a/m4/extern-inline.m4
+++ b/m4/extern-inline.m4
@@ -25,7 +25,8 @@ AC_DEFUN([gl_EXTERN_INLINE],
    if isdigit is mistakenly implemented via a static inline function,
    a program containing an extern inline function that calls isdigit
    may not work since the C standard prohibits extern inline functions
-   from calling static functions.  This bug is known to occur on:
+   from calling static functions (ISO C 99 section 6.7.4.(3).
+   This bug is known to occur on:
 
      OS X 10.8 and earlier; see:
      https://lists.gnu.org/r/bug-gnulib/2012-12/msg00023.html
@@ -38,7 +39,18 @@ AC_DEFUN([gl_EXTERN_INLINE],
 
    OS X 10.9 has a macro __header_inline indicating the bug is fixed for C and
    for clang but remains for g++; see <https://trac.macports.org/ticket/41033>.
-   Assume DragonFly and FreeBSD will be similar.  */
+   Assume DragonFly and FreeBSD will be similar.
+
+   GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99
+   inline semantics, unless -fgnu89-inline is used.  It defines a macro
+   __GNUC_STDC_INLINE__ to indicate this situation or a macro
+   __GNUC_GNU_INLINE__ to indicate the opposite situation.
+   GCC 4.2 with -std=c99 or -std=gnu99 implements the GNU C inline
+   semantics but warns, unless -fgnu89-inline is used:
+     warning: C99 inline functions are not supported; using GNU89
+     warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute
+   It defines a macro __GNUC_GNU_INLINE__ to indicate this situation.
+ */
 #if (((defined __APPLE__ && defined __MACH__) \
       || defined __DragonFly__ || defined __FreeBSD__) \
      && (defined __header_inline \