GNU bug report logs -
#44763
Error when 'make'ing latest version of coreutils
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44763 in the body.
You can then email your comments to 44763 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Fri, 20 Nov 2020 14:20:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Chris Elvidge <celvidge001 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 20 Nov 2020 14:20:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I keep getting
./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_ALIGNED_ALLOC@
^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_POSIX_MEMALIGN@
^
when running make in the latest version of coreutils.
Slackware 14.2 : 32-bit : VBox VM
I did:
git clone git://git.sv.gnu.org/coreutils
./bootstrap
git submodule foreach git pull origin master
git config --global user.email "celvidge001 <at> gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
./configure
make
Relevant lines from stdlib.h
'sed -n 690,700p ./lib/stdlib.h'
# endif
#endif
/* Allocate memory with indefinite extent and specified alignment. */
#if @GNULIB_ALIGNED_ALLOC@
# if @REPLACE_ALIGNED_ALLOC@
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# undef aligned_alloc
# define aligned_alloc rpl_aligned_alloc
# endif
'sed -n 1055,1065p ./lib/stdlib.h'
# define mktemp _mktemp
#endif
/* Allocate memory with indefinite extent and specified alignment. */
#if @GNULIB_POSIX_MEMALIGN@
# if @REPLACE_POSIX_MEMALIGN@
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# undef posix_memalign
# define posix_memalign rpl_posix_memalign
# endif
_GL_FUNCDECL_RPL (posix_memalign, int,
Can anyone help, please?
--
Chris Elvidge
5 Ebor Park, Appleton Roebuck, York. YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvidge <at> outlook.com
Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Fri, 20 Nov 2020 14:48:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44763 <at> debbugs.gnu.org (full text, mbox):
On 20/11/2020 14:19, Chris Elvidge wrote:
> I keep getting
>
> ./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
> expressions
> #if @GNULIB_ALIGNED_ALLOC@
> ^
> ./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
> expressions
> #if @GNULIB_POSIX_MEMALIGN@
Please update bison to >= 3.5.
I don't know what the exact new requirement is,
but will update bootstrap.conf to check that very soon.
Akim do you know the min bison version
now required by the latest gnulib?
That would spare me some bisecting.
thanks,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Fri, 20 Nov 2020 15:43:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.
On 20/11/2020 02:47 pm, Pádraig Brady wrote:
> On 20/11/2020 14:19, Chris Elvidge wrote:
>> I keep getting
>>
>> ./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
>> expressions
>> #if @GNULIB_ALIGNED_ALLOC@
>> ^
>> ./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
>> expressions
>> #if @GNULIB_POSIX_MEMALIGN@
>
> Please update bison to >= 3.5.
> I don't know what the exact new requirement is,
> but will update bootstrap.conf to check that very soon.
>
> Akim do you know the min bison version
> now required by the latest gnulib?
> That would spare me some bisecting.
>
> thanks,
> Pádraig
>
--
Chris Elvidge
5 Ebor Park, Appleton Roebuck, York. YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvidge <at> outlook.com
Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Fri, 20 Nov 2020 15:49:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 44763 <at> debbugs.gnu.org (full text, mbox):
On 20/11/2020 15:42, Chris Elvidge wrote:
> Updated to bison 3.7; installed in /usr/local/bin
> Unfortunately, still the same error
> Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
> No go.
> Thanks.
Did you rerun bootstrap?
What version was /usr/bin/bison ?
See also https://bugs.gnu.org/44739
thanks,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Fri, 20 Nov 2020 16:40:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Bison was 3.0.4. (configure checks for >2.4)
Now 3.7
Reran the whole thing from git clone etc.
(
git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap
git submodule foreach git pull origin master
git config --global user.email "celvidge001 <at> gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
./configure
)
'make' still fails with the same error message(s)
Cheers
On 20/11/2020 03:48 pm, Pádraig Brady wrote:
> On 20/11/2020 15:42, Chris Elvidge wrote:
>> Updated to bison 3.7; installed in /usr/local/bin
>> Unfortunately, still the same error
>> Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
>> No go.
>> Thanks.
>
> Did you rerun bootstrap?
> What version was /usr/bin/bison ?
> See also https://bugs.gnu.org/44739
>
> thanks,
> Pádraig
>
--
Chris Elvidge
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 06:36:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Hi Pádraig,
> Le 20 nov. 2020 à 15:47, Pádraig Brady <P <at> draigBrady.com> a écrit :
>
> On 20/11/2020 14:19, Chris Elvidge wrote:
>> I keep getting
>> ./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
>> expressions
>> #if @GNULIB_ALIGNED_ALLOC@
>> ^
>> ./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
>> expressions
>> #if @GNULIB_POSIX_MEMALIGN@
>
> Please update bison to >= 3.5.
> I don't know what the exact new requirement is,
> but will update bootstrap.conf to check that very soon.
>
> Akim do you know the min bison version
> now required by the latest gnulib?
> That would spare me some bisecting.
I wasn't aware of any strong dependency such as this one (and I actually
still have not understood what the problem is, and how problems with
AC_SUBST are related to Bison here).
The only I see in gnulib which is a *.y is lib/parse-datetime.y.
And I don't see anything special in it that would require any special
version of Bison.
Just in case:
$ for i in /usr/local/stow/bison-3.*
do
echo "$i..."
$i/bin/bison lib/parse-datetime.y
done
/usr/local/stow/bison-3.0.5...
/usr/local/stow/bison-3.1...
/usr/local/stow/bison-3.2.4...
/usr/local/stow/bison-3.3.2...
/usr/local/stow/bison-3.4.2...
/usr/local/stow/bison-3.5.4...
/usr/local/stow/bison-3.6.4...
/usr/local/stow/bison-3.7...
/usr/local/stow/bison-3.7.1...
/usr/local/stow/bison-3.7.2...
/usr/local/stow/bison-3.7.3...
I think I have not understood the question, sorry :( What exactly
happens here? Is configure properly rerun each time, without cache?
Why are we talking about Bison?
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 07:02:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Hi guys,
> Le 21 nov. 2020 à 07:35, Akim Demaille <akim.demaille <at> gmail.com> a écrit :
>
> Hi Pádraig,
>
> Just in case:
>
> $ for i in /usr/local/stow/bison-3.*
I had forgotten that there is a 2.3 sitting on my system, and indeed:
$ /usr/bin/bison gnulib/lib/parse-datetime.y
gnulib/lib/parse-datetime.y:555.9-16: syntax error, unexpected identifier, expecting string
It chokes on `%define api.pure`.
According to NEWS, this syntax was introduced in 2.4 (2008-11-02).
I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that were not covered by gnulib at
that time). I cannot even install 3.0.
Cheers!
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 13:18:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 44763 <at> debbugs.gnu.org (full text, mbox):
On 21/11/2020 07:01, Akim Demaille wrote:
> Hi guys,
>
>> Le 21 nov. 2020 à 07:35, Akim Demaille <akim.demaille <at> gmail.com> a écrit :
>>
>> Hi Pádraig,
>>
>> Just in case:
>>
>> $ for i in /usr/local/stow/bison-3.*
>
> I had forgotten that there is a 2.3 sitting on my system, and indeed:
>
> $ /usr/bin/bison gnulib/lib/parse-datetime.y
> gnulib/lib/parse-datetime.y:555.9-16: syntax error, unexpected identifier, expecting string
>
> It chokes on `%define api.pure`.
>
> According to NEWS, this syntax was introduced in 2.4 (2008-11-02).
>
> I have tried to install 2.7 on my system, but I can't (because of
> portability issues of vasnprintf that were not covered by gnulib at
> that time). I cannot even install 3.0.
Thanks a lot for checking.
The info in https://bugs.gnu.org/44739 must be incorrect,
and we've two counter checks to it now.
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 13:18:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 44763 <at> debbugs.gnu.org (full text, mbox):
On 11/20/20 5:38 PM, Chris Elvidge wrote:
> Reran the whole thing from git clone etc.
> (
> git clone git://git.sv.gnu.org/coreutils
> cd coreutils
> ./bootstrap
> git submodule foreach git pull origin master
> git config --global user.email "celvidge001 <at> gmail.com"
> git config --global user.name "Chris Elvidge"
> git commit -m 'build: update gnulib submodule to latest' gnulib
> ./configure
> )
In general it is advised that one has to
git clean -xdfq \
&& ./bootstrap
again after a gnulib update.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 14:38:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Well, that got me a bit further. Thanks.
Now the error from 'make' is:
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 '_'
cc1: all warnings being treated as errors
Makefile:9842: recipe for target 'lib/parse-datetime.o' failed
make[2]: *** [lib/parse-datetime.o] Error 1
make[2]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:12479: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:6581: recipe for target 'all' failed
make: *** [all] Error 2
I tried ./configure TIME_T_32_BIT_OK=yes - didn't make any difference.
I'm going to try again from scratch.
I'll let you know.
On 21/11/2020 01:17 pm, Bernhard Voelker wrote:
> On 11/20/20 5:38 PM, Chris Elvidge wrote:
>> Reran the whole thing from git clone etc.
>> (
>> git clone git://git.sv.gnu.org/coreutils
>> cd coreutils
>> ./bootstrap
>> git submodule foreach git pull origin master
>> git config --global user.email "celvidge001 <at> gmail.com"
>> git config --global user.name "Chris Elvidge"
>> git commit -m 'build: update gnulib submodule to latest' gnulib
>> ./configure
>> )
>
> In general it is advised that one has to
>
> git clean -xdfq \
> && ./bootstrap
>
> again after a gnulib update.
>
> Have a nice day,
> Berny
>
--
Chris Elvidge
5 Ebor Park, Appleton Roebuck, York. YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvidge <at> outlook.com
Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 15:55:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Still no luck. Same error in parse-datetime.y
Cheers
On 21/11/2020 01:17 pm, Bernhard Voelker wrote:
> On 11/20/20 5:38 PM, Chris Elvidge wrote:
>> Reran the whole thing from git clone etc.
>> (
>> git clone git://git.sv.gnu.org/coreutils
>> cd coreutils
>> ./bootstrap
>> git submodule foreach git pull origin master
>> git config --global user.email "celvidge001 <at> gmail.com"
>> git config --global user.name "Chris Elvidge"
>> git commit -m 'build: update gnulib submodule to latest' gnulib
>> ./configure
>> )
>
> In general it is advised that one has to
>
> git clean -xdfq \
> && ./bootstrap
>
> again after a gnulib update.
>
> Have a nice day,
> Berny
>
--
Chris Elvidge
5 Ebor Park, Appleton Roebuck, York. YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvidge <at> outlook.com
Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 16:54:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Hi all,
> Le 20 nov. 2020 à 16:48, Pádraig Brady <P <at> draigBrady.com> a écrit :
>
> See also https://bugs.gnu.org/44739
There, I just read this:
>> I found that I needed to upgrade to Bison v3.7.4 to avoid a build error
>> in stdlib.h where @GNULIB_POSIX_MEMALIGN@ has not been converted by
>> Bison. The check in your bootstrap program allows for an older version
>> of Bison to be used which fails to do the necessary conversion.
which is not correct. Bison does not perform any transformation
on @FOO@ at all. This is completely unrelated to it. What would
be most useful is to get the generated files and see what they
look like.
Also, I might have missed messages, but I would like to see a
plain copy-paste of the terminal where I can see exactly what
commands were run, and what the tools reported.
Cheers!
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 17:35:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 44763 <at> debbugs.gnu.org (full text, mbox):
These are the commands as run:
git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap | tee -a out_bootstrap.1
git submodule foreach git pull origin master
git config --global user.email "celvidge001 <at> gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
git clean -xdfq && ./bootstrap | tee -a out_bootstrap.2
./configure TIME_T_32_BIT_OK=yes | tee -a out_configure.1
I've got the output of the second bootstrap run (git clean deleted the
first one, I think) and the configure run.
However I've only got the error message at the end on the make run.
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 '_'
cc1: all warnings being treated as errors
Makefile:9842: recipe for target 'lib/parse-datetime.o' failed
make[2]: *** [lib/parse-datetime.o] Error 1
make[2]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:12479: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:6581: recipe for target 'all' failed
make: *** [all] Error 2
I'll send the 30K gzipped file direct to Akim separately, if that's OK.
Cheers
On 21/11/2020 04:53 pm, Akim Demaille wrote:
> Hi all,
>
>> Le 20 nov. 2020 à 16:48, Pádraig Brady <P <at> draigBrady.com> a écrit :
>>
>> See also https://bugs.gnu.org/44739
>
> There, I just read this:
>
>>> I found that I needed to upgrade to Bison v3.7.4 to avoid a build error
>>> in stdlib.h where @GNULIB_POSIX_MEMALIGN@ has not been converted by
>>> Bison. The check in your bootstrap program allows for an older version
>>> of Bison to be used which fails to do the necessary conversion.
>
> which is not correct. Bison does not perform any transformation
> on @FOO@ at all. This is completely unrelated to it. What would
> be most useful is to get the generated files and see what they
> look like.
>
> Also, I might have missed messages, but I would like to see a
> plain copy-paste of the terminal where I can see exactly what
> commands were run, and what the tools reported.
>
> Cheers!
>
--
Chris Elvidge
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 18:15:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Hi Chris,
I saw nothing suspicious about Bison in the logs you sent.
> Le 21 nov. 2020 à 18:33, Chris Elvidge <celvidge001 <at> 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!
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 19:56:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 44763 <at> debbugs.gnu.org (full text, mbox):
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 <celvidge001 <at> 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
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 21:17:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 44763 <at> debbugs.gnu.org (full text, mbox):
[adding Paul]
On 11/21/20 8:54 PM, Chris Elvidge wrote:
> 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
I see the same with gcc-10.2.1 here.
It happens since:
https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=bd90572c031
Paul removed the return statement because Sun C 5.9 complains about it.
static void *
threadN_func (void *arg)
{
for (;;)
{
nl_langinfo (CODESET); /* LC_CTYPE */ /* locale charmap */
nl_langinfo (AM_STR); /* LC_TIME */ /* locale -k am_pm */
nl_langinfo (PM_STR); /* LC_TIME */ /* locale -k am_pm */
nl_langinfo (DAY_2); /* LC_TIME */ /* locale -k day */
nl_langinfo (DAY_5); /* LC_TIME */ /* locale -k day */
nl_langinfo (ALTMON_2); /* LC_TIME */ /* locale -k alt_mon */
nl_langinfo (ALTMON_9); /* LC_TIME */ /* locale -k alt_mon */
nl_langinfo (CRNCYSTR); /* LC_MONETARY */ /* locale -k currency_symbol */
nl_langinfo (RADIXCHAR); /* LC_NUMERIC */ /* locale -k decimal_point */
nl_langinfo (THOUSEP); /* LC_NUMERIC */ /* locale -k thousands_sep */
}
/*NOTREACHED*/
- return NULL;
}
How to fix?
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sat, 21 Nov 2020 23:46:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 44763 <at> debbugs.gnu.org (full text, mbox):
Finally! Got make, make _version, make check, make install finished.
Here's my instruction file, run from Downloads directory (sorry about
the wordwrap, should be obvious though)
outfiles="$(pwd)/outfiles"
[ -d "$outfiles" ] || mkdir -p $outfiles
git clone git://git.sv.gnu.org/coreutils 2>&1 | tee -a
$outfles/out_git_clone.1.txt
cd coreutils
./bootstrap 2>&1 | tee -a $outfiles/out_bootstrap.1.txt
git submodule foreach git pull origin master 2>&1 | tee -a
$outfiles/out_submodule.1.txt
# these should changed to reflect user
git config --global user.email "celvidge001 <at> gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 |
tee -a $outfiles/out_commit.1.txt
# Berny's addition
git clean -xdfq && ./bootstrap 2>&1 | tee -a $outfiles/out_bootstrap.2.txt
./configure 2>&1 | tee -a $outfiles/out_configure.1.txt
# do edit to make make work
# Akim's change - make it expect a long not a long long
sed -i -e '2301s/%"PRIdMAX"/%ld/' lib/parse-datetime.y
sed -n 2301p lib/parse-datetime.y
# do three edits to make make check work
# put 'return NULL;' back before '/*NOTREACHED*/' # explained by Berny
sed -i -e '184s#\(/\*NOTREACHED\*/\)#return NULL; \1#'
gnulib/tests/test-nl_langinfo-mt.c
sed -n 184p gnulib/tests/test-nl_langinfo-mt.c
sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#'
gnulib/tests/test-setlocale_null-mt-all.c
sed -n 94p gnulib/tests/test-setlocale_null-mt-all.c
sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#'
gnulib/tests/test-setlocale_null-mt-one.c
sed -n 94p gnulib/tests/test-setlocale_null-mt-one.c
# pause here to make sure edits done properly
read -p "Press return to continue" junk
make 2>&1 | tee -a $outfiles/out_make.1.txt
# install complains if this not done
make _version | tee -a $outfiles/out_make.2.txt
make check | tee -a $outfiles/out_make.3.txt
Cheers all!!
On 21/11/2020 09:16 pm, Bernhard Voelker wrote:
> [adding Paul]
>
> On 11/21/20 8:54 PM, Chris Elvidge wrote:
>> 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
>
> I see the same with gcc-10.2.1 here.
>
> It happens since:
> https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=bd90572c031
>
> Paul removed the return statement because Sun C 5.9 complains about it.
>
> static void *
> threadN_func (void *arg)
> {
> for (;;)
> {
> nl_langinfo (CODESET); /* LC_CTYPE */ /* locale charmap */
> nl_langinfo (AM_STR); /* LC_TIME */ /* locale -k am_pm */
> nl_langinfo (PM_STR); /* LC_TIME */ /* locale -k am_pm */
> nl_langinfo (DAY_2); /* LC_TIME */ /* locale -k day */
> nl_langinfo (DAY_5); /* LC_TIME */ /* locale -k day */
> nl_langinfo (ALTMON_2); /* LC_TIME */ /* locale -k alt_mon */
> nl_langinfo (ALTMON_9); /* LC_TIME */ /* locale -k alt_mon */
> nl_langinfo (CRNCYSTR); /* LC_MONETARY */ /* locale -k currency_symbol */
> nl_langinfo (RADIXCHAR); /* LC_NUMERIC */ /* locale -k decimal_point */
> nl_langinfo (THOUSEP); /* LC_NUMERIC */ /* locale -k thousands_sep */
> }
>
> /*NOTREACHED*/
> - return NULL;
> }
>
> How to fix?
>
> Have a nice day,
> Berny
>
--
Chris Elvidge
5 Ebor Park, Appleton Roebuck, York. YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvidge <at> outlook.com
Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sun, 22 Nov 2020 03:13:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 44763 <at> debbugs.gnu.org (full text, mbox):
On 11/21/20 5:17 AM, Pádraig Brady wrote:
> The info in https://bugs.gnu.org/44739 must be incorrect,
> and we've two counter checks to it now.
Yes, that sounds right. Closing that bug report.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#44763
; Package
coreutils
.
(Sun, 22 Nov 2020 03:18:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 44763 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 11/21/20 6:37 AM, Chris Elvidge wrote:
> 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=]
That's due to a typo that I recently introduced to parse-datetime.y. Thanks for
reporting it. (I didn't observe the problem since I tested on hosts with 64-bit
time_t, not 32-bit.) I installed the attached patch into Gnulib and propagated
this into Coreutils.
[0001-parse-datetime-fix-printf-format-typo.patch (text/x-patch, attachment)]
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Sun, 22 Nov 2020 03:23:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Chris Elvidge <celvidge001 <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 22 Nov 2020 03:23:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 44763-done <at> debbugs.gnu.org (full text, mbox):
Thanks for reporting your recipe for working around all these problems. I've
installed patches for the problems into coreutils and gnulib and am closing the
bug report.
On 11/21/20 3:45 PM, Chris Elvidge wrote:
> git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 | tee -a
> $outfiles/out_commit.1.txt
I suggest doing the bootstrap after this 'git commit', not earlier.
Because of the abovementioned patches, you should no longer need to do the
following steps:
> # Berny's addition
> git clean -xdfq && ./bootstrap 2>&1 | tee -a $outfiles/out_bootstrap.2.txt
>
> ./configure 2>&1 | tee -a $outfiles/out_configure.1.txt
>
> # do edit to make make work
> # Akim's change - make it expect a long not a long long
> sed -i -e '2301s/%"PRIdMAX"/%ld/' lib/parse-datetime.y
> sed -n 2301p lib/parse-datetime.y
>
> # do three edits to make make check work
> # put 'return NULL;' back before '/*NOTREACHED*/' # explained by Berny
> sed -i -e '184s#\(/\*NOTREACHED\*/\)#return NULL; \1#'
> gnulib/tests/test-nl_langinfo-mt.c
> sed -n 184p gnulib/tests/test-nl_langinfo-mt.c
> sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#'
> gnulib/tests/test-setlocale_null-mt-all.c
> sed -n 94p gnulib/tests/test-setlocale_null-mt-all.c
> sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#'
> gnulib/tests/test-setlocale_null-mt-one.c
> sed -n 94p gnulib/tests/test-setlocale_null-mt-one.c
>
> # pause here to make sure edits done properly
> read -p "Press return to continue" junk
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 20 Dec 2020 12:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 210 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.