Update gnulib to current upstream master

  On Wednesday, August 29 2018, Pedro Alves wrote:

> On 08/28/2018 08:59 PM, Sergio Durigan Junior wrote:
>> [ Disclaimer: I'm sending the patch gzipped because I'm afraid
>> sourceware won't accept a 1.2MB message. ]
>> 
>> It has been a while since we don't update our gnulib copy against
>> their upstream master branch, so I thought I'd propose this patch.  It
>> also fixes (at least) one bug reported against GDB:
>> 
>>   https://sourceware.org/bugzilla/show_bug.cgi?id=23558
>> 
>> The problem reported there is about the replacement of 'getcwd' when
>> cross-compiling GDB.  With our current gnulib copy, the mechanism for
>> deciding whether to use the system's 'getcwd' or gnulib's version is
>> too simplistic and pessimistic, so when cross-compiling we always end
>> up using gnulib's version, which has a limitation: it cannot handle
>> the situation when the parent directory doesn't have read permissions.
>> 
>> This has been reported against upstream gnulib and the fix has been
>> pushed here:
>> 
>>   https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=a96d2e67052c879b1bcc5bc461722beac75fc372
>> 
>> I regtested this patch on Fedora 28 x86-64, and there were no
>> regressions.
>> 
>> OK?
>
> It is standard practice when updating gnulib to discuss the set of
> modules that the exercise brings in due to module dependencies.
> If we're now including some more modules, that may mean that
> we could eliminate some older host compatibility code from gdb
> in favor of gnulib's and list the module dependencies
> explicitly in IMPORTED_GNULIB_MODULES in update-gnulib.h.
>
> Conversely, there's a chance that we were depending on some
> module that wasn't explicitly listed in IMPORTED_GNULIB_MODULES,
> and an update could remove the module by mistake.

Hm, OK, I didn't think about this scenario, so I didn't bother including
the list of modules that were pulled when updating gnulib.

So, I ran the gnulib update process twice, once for our previous
version, and once for the new version (that I pushed).  The differences
are:
  

On 08/29/2018 08:34 PM, Sergio Durigan Junior wrote:
> --- /tmp/gnulib1.txt	2018-08-29 15:20:56.394418711 -0400
> +++ /tmp/gnulib2.txt	2018-08-29 15:22:57.846895510 -0400
> @@ -4,13 +4,14 @@
>      alloca-opt
>      assure
>      at-internal
> +    builtin-expect
> +    c99
>    canonicalize-lgpl
>      chdir
>      chdir-long
>      cloexec
>      close
>      closedir
> -    configmake
>      d-ino
>      d-type
>    dirent
> @@ -30,6 +31,7 @@
>      fcntl
>      fcntl-h
>      fd-hook
> +    fd-safer-flag
>      fdopendir
>      filename
>      filenamecat-lgpl
> @@ -37,6 +39,7 @@
>      float
>      fnmatch
>    fnmatch-gnu
> +    fnmatch-h

We have a fnmatch.h replacement file in src/include/, and we include
fnmatch.h using quotes ("fnmatch.h").  Hopefully this won't cause weird
definition mismatches on hosts where gnulib provides a replacement.
Let's keep an eye out on that.

>      fpieee
>      fpucw
>      frexp
> @@ -51,6 +54,7 @@
>      gettext-h
>      gettimeofday
>    glob
> +    glob-h
>      hard-locale
>      include_next
>      intprops
> @@ -59,8 +63,10 @@
>      isnand-nolibm
>      isnanl-nolibm
>      largefile
> +    libc-config
>    limits-h
>      localcharset
> +    localtime-buffer
>    lstat
>      malloc-posix
>      malloca
> @@ -94,7 +100,7 @@
>      rmdir
>      same-inode
>      save-cwd
> -    secure_getenv
> +    scratch_buffer
>    setenv
>    signal-h
>      snippet/_Noreturn
> @@ -103,8 +109,10 @@
>      snippet/warn-on-use
>      ssize_t
>      stat
> +    stat-time
> +    std-gnu11

I wonder whether we should be using std-gnu11 explicitly.

>      stdbool
>      stddef
>      stdint
>      stdio
>      stdlib
> @@ -130,40 +138,36 @@
>      verify
>    wchar
>    wctype-h
> +    xalloc-oversized
> 
> 
> It doesn't seem like we're importing any important module implicity, nor
> that we stopped important anything important, but I may be wrong.
> 

Agreed, I crosschecked the list diff above against
<https://www.gnu.org/software/gnulib/MODULES.html>, following the links
in the leftmost column to check relevant module descriptions, and in some
cases looked at the sources of the modules.  Nothing big stood out to me.

>> Should we cherry pick the getcwd fix to the 8.2 branch?
> If you're proposing cherry-picking only the patch to the .m4 file under
> the gnulib/ dir, then perhaps we could.  

This, cherry-pick the getcwd fix that was applied on the gnulib tree.

> Backporting the whole gnulib
> update is not a good idea, IMHO.  But I'm sure that's not what you
> meant.

That's not what I meant.

Thanks,
Pedro Alves