This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Update gnulib to current upstream master
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