[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) |
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’.