Hi Chris,
I saw nothing suspicious about Bison in the logs you sent.
> Le 21 nov. 2020 à 18:33, Chris Elvidge <celvidge...@gmail.com> 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!
