Re: [PATCH] Update gnulib to current upstream master

[Sergio Durigan Junior <sergiodj@redhat.com>]

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:

--- /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
     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
     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.

> Another reason for that is that that are some modules that
> are problematic for us (e.g., the one that pulls in Windows's
> select replacement), so we need to look out for that, in case
> it is pulled in by a dependency.

It seems we're still covered.

> Also, if there were newer m4 files or m4 files deleted, I think we
> we need to update the list in gnulib/Makefile.in (aclocal_m4_deps).

As I said on IRC, I had no idea we needed to manually edit any other
file, especially one that's under the gnulib/ dir.  But I'll do it and
propose a patch.

> 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.  Backporting the whole gnulib
update is not a good idea, IMHO.  But I'm sure that's not what you
meant.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/