[Top][All Lists]

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

Re: ‘mktime’ replacement on glibc systems

From: Paul Eggert
Subject: Re: ‘mktime’ replacement on glibc systems
Date: Sun, 3 Jul 2016 13:13:22 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

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 ();
   tzset ();
--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.

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

reply via email to

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