[tz] zic.c - compilation broken on gcc 4.8.3 after commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6

[Иванов Игорь]

Thank you, Paul. I've checked the main branch and the issue with undeclared
variables is gone now.

I will also dare to mention another issue in this same thread, as it is kinda
part of the same story (us trying to build tz on older gcc / glibc / distro).
In our case, linker fails with:

    zic.o: In function `get_rand_u64':
    zic.c:(.text+0x1978): undefined reference to `clock_gettime'

Usage of clock_gettime was introduced in the commit

    commit 0733c65c14c424b5d9de5ee250a8bf2802a0b259
    Author: Paul Eggert <eggert at cs.ucla.edu>
    Date:   Thu Oct 20 12:35:54 2022 -0700
        Improve randomness of zic temp file names

The problem is that our distro uses glibc-2.15. In these ancient times, to use
`clock_*` functions you had to link against `rt` library - but since version
glibc-2.17 these functions are a part of standard C library. The problem can
be easily fixed from our side, just by adding a link flag to build command:

    make LDFLAGS='-lrt' ...

Since even Centos 7 nowadays uses glibc-2.17, I doubt that one should tinker
with tz code to account for this case - but it might be worthy mentioning this
somewhere in readme. Or not.
________________________________
From: Paul Eggert <eggert at cs.ucla.edu>
Sent: Saturday, October 29, 2022 00:53
To: Иванов Игорь <i.ivanov at dssl.ru>
Cc: Time zone mailing list <tz at iana.org>
Subject: Re: [tz] zic.c - compilation broken on gcc 4.8.3 after commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6

On 2022-10-28 07:43, Иванов Игорь via tz wrote:

> Apparently it breaks #if preprocessor logic in older compilers somewhere downstream - what was #if 1 becomes #if true, which GCC treats as "false" and falls into #else branch.

Thanks for reporting the problem. I think the problem is in the
HAS_INCLUDE macro, which now that I look at it more closely doesn't
conform to C23 either. Although I doubt whether the problem is the
true/false stuff I'll move those macros earlier just in case; that's
more robust anyway.

Please try the attached patch, which I installed into the development
repository on GitHub.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20221031/30f9592d/attachment.html>