bug#27736: OSX 10.6.8: Building from master branch fails.

[charles@aurox.ch (Charles A. Roelli)]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 27 Mar 2018 14:19:22 -0700
> 
> > >     (<= m -1034058203136)
> > >     (<= m -1034058203135))
> Unfortunately these numbers don't fit into a 30-bit integer and so they 
> run afoul of a portability issue, namely, that files byte-compiled on a 
> 64-bit Emacs should run on a 32-bit Emacs and vice versa. I noticed this 
> problem when preparing a patch to catch this sort of issue. To fix this 
> particular instance of the problem, I attempted to migrate the localtime 
> workaround into editfns.c (so that the fix is more-general, and is not 
> limited to org-clock), by installing the attached patches into master. 
> Please give them a try, since I don't have easy access to Mac OS X. I'm 
> still a bit fuzzy on exactly which timestamps cause Mac OS X localtime 
> to go belly-up (is it timezone dependent?), so quite possibly the magic 
> numbers in these patches need to be adjusted a bit so that the code will 
> work in any timezone from TZ=AAA-24:59:59 to TZ=ZZZ24:59:59; please let 
> me know.

Thank you for looking into this.  At the moment, on an affected
system, ./configure has the following output:

  checking whether localtime loops forever near extrema... no

and config.log shows:

  configure:30520: checking whether localtime loops forever near extrema
  configure:30554: gcc -std=gnu99 -o conftest -O0 -g3     conftest.c   >&5
  configure:30554: $? = 0
  configure:30554: ./conftest
  configure:30554: $? = 0
  configure:30562: result: no

Bizarrely, the problem doesn't seem to show itself exactly in the
range I had quoted last July on bug-gnulib, so I applied the following
small change, with which the hang was detected.

--- a/m4/time_rz.m4
+++ b/m4/time_rz.m4
@@ -26,7 +26,7 @@ AC_DEFUN
             #include <unistd.h>
             #include <time.h>
           ]], [[
-            time_t t = -67768038400665600;
+            time_t t = -67768038400666600;
             struct tm *tm;
             char *tz = getenv ("TZ");
             if (! (tz && strcmp (tz, "QQQ0") == 0))

And then I got the following in the output of ./configure:

  checking whether localtime loops forever near extrema... ./configure: line 30561: 35760 Alarm clock             TZ=QQQ0 ./conftest$EXEEXT
  yes

(The rest of the compilation process worked fine, so this change is on
the right track.)

I will try to find the exact boundary of the hang again.  And the hang
is timezone-dependent, so that complicates things too.