Re: [PATCH] Update gnulib to current trunk

[Tom de Vries <tdevries@suse.de>]

On 7/16/20 4:56 PM, Pedro Alves wrote:
> On 7/6/20 7:19 PM, Christian Biesinger wrote:
>> Fair enough. This is the module diff:
>>
>> --- /tmp/old 2020-07-06 13:04:17.837482577 -0500
>> +++ /tmp/new 2020-07-06 13:02:48.636984706 -0500
>> @@ -1,9 +1,12 @@
>> +Module list with included dependencies (indented):
>>      absolute-header
>>    alloca
>>      alloca-opt
>>      arpa_inet
>>      assure
>>      at-internal
>> +    attribute
>> +    btowc
> 
> I wonder whether "btowc" potentially conflicts with the logic
> in gdb/gdb_wchar.h .  We should keep an eye out for that.
> 
> 
>>      builtin-expect
>>      c99
>>    canonicalize-lgpl
>> @@ -13,12 +16,12 @@
>>      close
>>      closedir
>>    count-one-bits
>> +    ctype
>>      d-ino
>>      d-type
>>    dirent
>>    dirfd
>>      dirname-lgpl
>> -    dosname
>>      double-slash-root
>>      dup
>>      dup2
>> @@ -52,8 +55,8 @@
>>      getdtablesize
>>      getlogin_r
>>      getprogname
>> +    getrandom
>>      gettext-h
>> -    gettimeofday
>>    glob
>>      glob-h
>>      hard-locale
>> @@ -62,6 +65,7 @@
>>      intprops
>>    inttypes
>>      inttypes-incomplete
>> +    isblank
>>      isnand-nolibm
>>      isnanl-nolibm
>>      largefile
>> @@ -69,7 +73,6 @@
>>    limits-h
>>      localcharset
>>      locale
>> -    localtime-buffer
>>      lock
>>    lstat
>>      malloc-posix
>> @@ -78,11 +81,13 @@
>>      mbrtowc
>>      mbsinit
>>      mbsrtowcs
>> +    mbtowc
>>    memchr
>>    memmem
>>      memmem-simple
>>      mempcpy
>>      memrchr
>> +    minmax
>>    mkdir
>>    mkdtemp
>>    mkostemp
>> @@ -132,13 +137,14 @@
>>      strerror-override
>>    strerror_r-posix
>>      string
>> +    strnlen
>>      strnlen1
>>    strstr
>>      strstr-simple
>>    strtok_r
>> +    sys_random
>>      sys_socket
>>    sys_stat
>> -    sys_time
>>      sys_types
>>      sys_uio
>>      tempname
>> @@ -156,5 +162,7 @@
>>      windows-once
>>      windows-recmutex
>>      windows-rwlock
>> +    wmemchr
>> +    wmempcpy
>>      xalloc-oversized
>>
>> It seems what is getting removed is:
>> -    dosname  (deprecated module and we don't use dosname.h)
>> -    gettimeofday (it looks like we use this in remote-fileio.c)
>> -    localtime-buffer (looks like basically an implementation detail)
>> -    sys_time (looks like GDB specifically did *not* want this per
>> comments in gdbsupport/gdb_sys_time.h)
>>
>> So:
>> - For gettimeofday, the fixes in
>> https://www.gnu.org/software/gnulib/manual/html_node/gettimeofday.html#gettimeofday
>> don't look that important for gdb, but we could include the module.
>> Let me know if you want me to.
> 
> I guess it doesn't hurt to explicitly include it.  Might as well do it,
> since we use the function and have been using the module thus far.
> 
>>
>> - For sys_time, we could perhaps replace the #undef in gdb_sys_time.h
>> with an #error. Let me know.
> 
> I suspect this gnulib commit is what caused gettimeofday and sys_time to
> drop for us:
> 
>  commit 78f55d5374d6ff9b8460c48a42e924bf69775cd7
>  Author:     Paul Eggert <eggert@cs.ucla.edu>
>  AuthorDate: Sun May 31 20:15:25 2020 -0700
> 
>     tempname: merge from glibc and coreutils
> ...
>     * modules/tempname (Depends-on): Remove gettimeofday, sys_time.
>     Add getentropy, libc-config.
> 
> As we can see from your diff:
> 
>>    sys_stat
>> -    sys_time
>>      sys_types
>>      sys_uio
>>      tempname
> 
> tempname is a dependency of sys_stat.
> 
> Another option would be to just get rid of gdb_sys_time.h,
> i.e., revert all or most of:
> 
>  commit 438e1e427e8393de73d22617abe4d8eba0270e72
>  Author:     Pedro Alves <palves@redhat.com>
>  AuthorDate: Mon Aug 24 18:50:55 2015 +0100
> 
>     Prepare for gnulib update
> 
> But I'd be fine with just leaving this alone for now, in case
> gnulib brings back the dependency.  It's also the easiest thing to
> do (i.e., do nothing).
> 

Hi,

it's been four weeks since the last update here, and this is scheduled
for the 10.1 release, so ... ping.  Any news on this?

Thanks,
- Tom