Update gnulib to current upstream master
Commit Message
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:
Comments
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
@@ -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/