OK All. Thanks for all the help.
Whether the bison (3.0.2 -> 3.7) upgrade was needed seems to be a moot
point.
Berny's mod to the bootstrap process (adding a step just before
configure 'git clean -xdfq && ./bootstrap') got over the first error.
Akim's mod to lib/parse-datetime.y (below) cured the second error.
make-check
============================================================================
Testsuite summary for GNU coreutils 8.32.74-d889b
============================================================================
# TOTAL: 622
# PASS: 513
# SKIP: 109
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
but then:
CC test-nl_langinfo-mt.o
test-nl_langinfo-mt.c: In function 'threadN_func':
test-nl_langinfo-mt.c:185:1: error: no return statement in function
returning non-void [-Werror=return-type]
}
^
cc1: all warnings being treated as errors
Makefile:6586: recipe for target 'test-nl_langinfo-mt.o' failed
make[5]: *** [test-nl_langinfo-mt.o] Error 1
make[5]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:9494: recipe for target 'check-am' failed
make[4]: *** [check-am] Error 2
make[4]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:6691: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:9497: recipe for target 'check' failed
make[2]: *** [check] Error 2
make[2]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:12479: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:12956: recipe for target 'check' failed
make: *** [check] Error 2
As I didn't really care about the tests I did sudo make install which
said the version number was out-of-date ans asked for make _version.
I did that and then sudo make install again.
It all seems to have worked. --version reports 8.32.74-d889b-dirty
Thanks again
Cheers
On 21/11/2020 06:14 pm, Akim Demaille wrote:
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!
--
Chris Elvidge
