[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 ();
#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
- Re: ‘mktime’ replacement on glibc systems,
Paul Eggert <=