Subject: bug#44763: Error when 'make'ing latest version of coreutils

From: Akim Demaille <[email-masked]>
Date: Sat, 21 Nov 2020 19:14:08 +0100

Hi Chris,

I saw nothing suspicious about Bison in the logs you sent.

> Le 21 nov. 2020 à 18:33, Chris Elvidge <[email-masked]> a écrit :
> 
>  CC       lib/parse-datetime.o
> In file included from lib/gettext.h:26:0,
>                 from parse-datetime.y:71:
> parse-datetime.y: In function 'parse_datetime2':
> parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
> parse-datetime.y:2301:25: note: in expansion of macro '_'

This is the only error I spotted, and that corresponds to:

  2296	            dbg_printf (_("after time adjustment (%+"PRIdMAX" hours, "
  2297	                          "%+"PRIdMAX" minutes, "
  2298	                          "%+"PRIdMAX" seconds, %+d ns),\n"),
  2299	                        pc.rel.hour, pc.rel.minutes, pc.rel.seconds,
  2300	                        pc.rel.ns);
  2301	            dbg_printf (_("    new time = %"PRIdMAX" epoch-seconds\n"), t4);

with

        time_t t4;

so it appears we "only" have a portability issue where gnulib
believes %PRIdMAX is ok for time_t, but it is not.

The other guys (in the previous gdb_printf) are intmax_t:

/* Relative times.  */
typedef struct
{
  /* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
  intmax_t year;
  intmax_t month;
  intmax_t day;
  intmax_t hour;
  intmax_t minutes;
  intmax_t seconds;
  int ns;
} relative_time;

I have no idea what is the best course of action to fix the error
(a cast?  A configure check to fight the right printf format?  Changing
the type of t4?), but Chris, if you just want to build, then simply
change 2301 into

dbg_printf (_("    new time = %ld epoch-seconds\n"), t4);

That should do it.

Cheers!