Re: ‘mktime’ replacement on glibc systems

[Ludovic Courtès]

Hi,

Paul Eggert <address@hidden> skribis:

> 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?

Our code indirectly pulls ‘timegm’, which has:

--8<---------------cut here---------------start------------->8---
Depends-on:
time
mktime-internal [test $HAVE_TIMEGM = 0 || test $REPLACE_TIMEGM = 1]
time_r          [test $HAVE_TIMEGM = 0 || test $REPLACE_TIMEGM = 1]
--8<---------------cut here---------------end--------------->8---

I guess the conditional is meant to avoid triggering the dependency.
However, in spite of:

--8<---------------cut here---------------start------------->8---
$ grep -E '(HAVE|REPLACE)_TIMEGM=' config.log
HAVE_TIMEGM='1'
REPLACE_TIMEGM='0'
--8<---------------cut here---------------end--------------->8---

… ‘gl_FUNC_MKTIME_INTERNAL’ is expanded and ends up setting
REPLACE_MKTIME=1.  IOW, the conditional does not prevent
mktime-internal’s configure snippet from being run.

Any idea how to address it?

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

Great, thank you!

Ludo’.