[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ‘mktime’ replacement on glibc systems

From: Ludovic Courtès
Subject: Re: ‘mktime’ replacement on glibc systems
Date: Mon, 04 Jul 2016 09:53:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]