Re: ‘mktime’ replacement on glibc systems

[Paul Eggert]

On 06/30/2016 10:21 AM, Ludovic Courtès wrote:
> Gnulib’s ‘mktime’ replacement gets used on glibc systems (glibc 2.22
> here) due to ‘__mktime_internal’ being unavailable, even though
> gl_cv_func_working_mktime=yes on these systems.  Is this intended?

No, and I don't observe it on Fedora 23 x86-64, which uses glibc 2.22. I 
ran './gnulib-tool --create-testdir --dir foo mktime; cd foo; 
./configure; make' and the resulting build did not compile mktime.c.

Perhaps your package is using the mktime-internal module? That would 
explain why mktime.c is getting compiled for you. If not, could you 
investigate why your package is compiling mktime.c even when glibc 2.22 
is being used?

> I believe “#ifdef _LIBC” should be changed to something like:
>
> --8<---------------cut here---------------start------------->8---
> #ifdef _LIBC
>    __tzset ();
> #else
>    tzset ();
> #endif
> --8<---------------cut here---------------end--------------->8---
>
> otherwise the current ‘TZ’ variable value ends up being ignored (we
> noticed this problem with Guile’s test suite.)

Yes, thanks, the old code dated back to when the substitute mktime.c was 
not intended to be thread-safe and so used localtime instead of 
localtime_r, so there was no need to call tzset. I installed the 
attached patch to fix that.

0001-mktime-call-tzset-as-per-POSIX.patch
Description: Text Data