🚀 go-pugleaf

Autoconf 1.1 on a 486 running Interactive Unix 2.2.1.  (Someone else
recently reported this problem for another system.)

In AC_TIMEZONE, the declaration of `tzname' is a problem. The decl in
AC_TIMEZONE is `extern char **tzname'.  This conflicts with the system
declaration

   extern char      *tzname[2];

and so Autoconf thinks the system doesn't have tzname.  This leads to
`date' dumping core when it tries to call tzname as a function, or
something like that.  (I didn't investigate it fully, since it seemed to
me the right fix was to make Autoconf think the system had tzname[] if
in fact it does.)

Anyway, since the declaration above is the one recommended by POSIX (for
some reason), I think we should support it.  I fixed it below simply by
removing the declaration from the test file to compile.

A more difficult but perhaps better alternative would be to see if
tzname is in fact declared in <time.h>, and, if not, put in the default
`extern char **tzname;'.  I don't know if there are in fact systems
which have tzname but do not declare it.

Sun Sep  6 10:33:07 1992  Karl Berry  (karl@hayley)

        * AC_TIMEZONE: do not declare tzname, as it might conflict with
          <time.h>.

*** acspecific.m4	Mon Aug 24 16:26:51 1992
--- /usr/local/gnu/lib/acspecific.m4	Sun Sep  6 10:15:36 1992
***************
*** 483,491 ****
  [struct tm tm; tm.tm_zone;], AC_DEFINE(HAVE_TM_ZONE), no_tm_zone=1)
  if test -n "$no_tm_zone"; then
  AC_COMPILE_CHECK(tzname, [#include <time.h>
! #ifndef tzname /* For SGI.  */
! extern char **tzname;
! #endif], [atoi(*tzname);], AC_DEFINE(HAVE_TZNAME))
  fi
  ])dnl
  dnl
--- 483,489 ----
  [struct tm tm; tm.tm_zone;], AC_DEFINE(HAVE_TM_ZONE), no_tm_zone=1)
  if test -n "$no_tm_zone"; then
  AC_COMPILE_CHECK(tzname, [#include <time.h>
! ], [atoi(*tzname);], AC_DEFINE(HAVE_TZNAME))
  fi
  ])dnl
  dnl