bug#44763: Error when 'make'ing latest version of coreutils
Hi Chris,
I saw nothing suspicious about Bison in the logs you sent.
> Le 21 nov. 2020 à 18:33, Chris Elvidge 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!
bug#44763: Error when 'make'ing latest version of coreutils
Hi all, > Le 20 nov. 2020 à 16:48, Pádraig Brady 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!
bug#44763: Error when 'make'ing latest version of coreutils
Hi guys, > Le 21 nov. 2020 à 07:35, Akim Demaille 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!
bug#44763: Error when 'make'ing latest version of coreutils
Hi Pádraig, > Le 20 nov. 2020 à 15:47, Pádraig Brady 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?
bug#36739: maint: fix issues in syntax-check
Ping?
bug#36739: [PATCH] maint: fix issues in syntax-check
Hi!
I was trying to reproduce some error in gnulib's syntax-check, and faced a few
issues.
My builddirs are in a separate tree, with symlinks from the src tree to them.
So running git from builddir will never work.
There are other errors, that I was not addressed.
error_quotes
env.c:337: " error at: %s"), str);
ls.c:2780: _("error canonicalizing %s"), name);
ls.c:3199: _("error canonicalizing %s"), full_name);
maint.mk: Use quote() for error string arguments
Cheers!
From dd4e813ab7ee3a8d9d27ca8f5eb874f991fff9b8 Mon Sep 17 00:00:00 2001
From: Akim Demaille
Date: Sat, 20 Jul 2019 09:04:00 +0200
Subject: [PATCH] maint: fix issues in syntax-check
* cfg.mk (sc_prohibit_colon_redirection): Don't expect `|` to denote
the pipe character in git grep.
(sc_tests_executable)
(sc_case_insensitive_file_names)
(sc_some_programs_must_avoid_exit_failure)
(sc_prohibit_test_background_without_cleanup_)
(sc_prohibit_test_calls_print_ver_with_irrelevant_argument)
(sc_prohibit_test_ulimit_without_require_)
(sc_prohibit_test_background_without_cleanup_)
(sc_THANKS_in_duplicates)
*sc_prohibit_test_calls_print_ver_with_irrelevant_argument):
Don't expect builddir to be a descendant of srcdir.
(sc_strftime_check): Don't check file size against 0 when "N\nq\n" was
already put in the file.
* THANKS.in: Remove me.
---
THANKS.in | 1 -
cfg.mk| 39 ++-
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/THANKS.in b/THANKS.in
index 02b8ada1c..23b089754 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -25,7 +25,6 @@ Adam Klein akl...@debian.org
Adam Sampsona...@offog.org
Adrian Bunk b...@stusta.de
AIDA Shinra shi...@j10n.org
-Akim Demaille demai...@inf.enst.fr
Alain Magloire al...@qnx.com
Alan Iwii...@atm.ox.ac.uk
Alan Jenkinsalan-jenk...@tuffmail.co.uk
diff --git a/cfg.mk b/cfg.mk
index b0b758dd5..b589b40e3 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -121,6 +121,7 @@ sc_tests_list_consistency:
# Ensure that all version-controlled test scripts are executable.
sc_tests_executable:
@set -o noglob 2>/dev/null || set -f; \
+ cd $(srcdir); \
find_ext="-name '' "`printf -- "-o -name *%s " $(TEST_EXTENSIONS)`;\
find $(srcdir)/tests/ \( $$find_ext \) \! -perm -u+x -print\
| { sed "s|^$(srcdir)/||"; git ls-files $(srcdir)/tests/; } \
@@ -138,8 +139,8 @@ sc_ensure_gl_diffs_apply_cleanly:
# Avoid :>file which doesn't propagate errors
sc_prohibit_colon_redirection:
- @cd $(srcdir)/tests && GIT_PAGER= git grep -n ': *>.*||' \
- && { echo '$(ME): '"The leading colon in :> will hide errors" 1>&2; \
+ @cd $(srcdir)/tests && GIT_PAGER= git grep -En ': *>.*\|\|' \
+ && { echo '$(ME): '"The leading colon in :> will hide errors" >&2; \
exit 1; } \
|| :
@@ -407,7 +408,7 @@ check-programs-vs-x:
# Ensure we can check out on case insensitive file systems
sc_case_insensitive_file_names: src/uniq
- @git ls-files | sort -f | src/uniq -Di | grep . && \
+ @git -C $(srcdir) ls-files | sort -f | src/uniq -Di | grep . && \
{ echo "$(ME): the above file(s) conflict on case insensitive" \
" file systems" 1>&2; exit 1; } || :
@@ -445,20 +446,22 @@ sc_prohibit_stat_macro_address:
# Ensure that date's --help output stays in sync with the info
# documentation for GNU strftime. The only exception is %N and %q,
# which date accepts but GNU strftime does not.
+#
+# "info foo" fails with error, but not "info foo >/dev/null".
extract_char = sed 's/^[^%][^%]*%\(.\).*/\1/'
sc_strftime_check:
@if test -f $(srcdir)/src/date.c; then \
- grep '^ %. ' $(srcdir)/src/date.c | sort\
- | $(extract_char) > $@-src; \
- { echo N; echo q; \
- info libc date calendar format 2>/dev/null \
- | grep "^ *['\`]%.'$$"| $(extract_char); }| sort >$@-info;\
- if test $$(stat --format %s $@-info) != 2; then \
+ if info libc date calendar format 2>/dev/null | \
+ grep "^ *['\`]%.'$$" >$
bug#13280: od 8.19: inappropriate formatting of the man pages
Le 27 déc. 2012 à 12:42, Pádraig Brady a écrit : > Yes the grouping of that info wasn't optimum. > I've adjusted things a bit in the attached patch, > and the result can be seen in the attached pdf generated with: > man -t man/od.1 | ps2pdf - > od.pdf > Note since people like examples, as part of this I've added > an EXAMPLES section, that shows how to output a hexdump with od. Very nice! I notice that instead of the usual: Mandatory arguments to long options are mandatory for short options too. there is: All arguments to long options are mandatory for short options. which is not right since: −w[BYTES], −−width[=BYTES] output BYTES bytes per output line. 32 is implied when BYTES is not specified
bug#13280: od 8.19: inappropriate formatting of the man pages
(Wow, I had never realized that applying --program-prefix=g on od results in invoking god). You might consider this a bug, or not. Sorry for the noise if you don't. "man od" (well, in my case, yet another interesting command to type, with deep philosophical meaning) includes a section-like (in bold) title for: Traditional format specifications may be intermixed; they accumulate: but it does not for: TYPE is made up of one or more of these specifications: (also the next paragraph, "RADIX is d for…" seems to belong to the "TYPE" section, but it does not. So maybe another section-like separation would be nice). in roff-tongue: … \fB\-\-version\fR output version information and exit .SS "Traditional format specifications may be intermixed; they accumulate:" .TP … .TP \fB\-x\fR same as \fB\-t\fR x2, select hexadecimal 2\-byte units .PP If first and second call formats both apply, the second format is assumed if the last operand begins with + or (if there are 2 operands) a digit. An OFFSET operand means \fB\-j\fR OFFSET. LABEL is the pseudo\-address at first byte printed, incremented when dump is progressing. For OFFSET and LABEL, a 0x or 0X prefix indicates hexadecimal; suffixes may be . for octal and b for multiply by 512. .PP TYPE is made up of one or more of these specifications: .TP a named character, ignoring high\-order bit .TP c Cheers!
Re: copyright years: mass-update every January 1
Hi All! Le 28 juil. 09 à 02:36, Joel E. Denny a écrit : diff --git a/src/head.c b/src/head.c index c96f910..89b6ef9 100644 --- a/src/head.c +++ b/src/head.c @@ -1,6 +1,5 @@ /* head -- output first part of file(s) - Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software - Foundation, Inc. + Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software Foundation, Inc. While at it, why not standardize everything to 4 digits (I don't think we need to address the Y10k issues yet :), and to introduce intervals where applicable? Is there some legal thingy that forbids it? It might help making some lines smaller. + Copyright (C) 1989-1991, 1995-2006, 2008-2009 Free Software Foundation, Inc.
Re: new module: update-copyright [Re: copyright years: mass-update every January 1
Le 31 juil. 09 à 15:52, Joel E. Denny a écrit :
Hi Joel,
+# Format within margin.
+my $new_wrapped;
+my $text_margin = $margin - length($prefix);
+while (length($new))
+ {
+if (($new =~ s/^(.{1,$text_margin})(?: |$)//)
+|| ($new =~ s/^([\S]+)(?: |$)//))
+ {
+my $line = $1;
+$new_wrapped .= $new_wrapped ? "\n" : $leading;
+$new_wrapped .= "$prefix$line";
+ }
+else
+ {
+# Should be unreachable, but we don't want an
infinite
+# loop if it can be reached.
+die;
+ }
+ }
You might want to have a look at Text::Wrap.
Re: ``install -C'' / unnecessarily updating time stamps
Le 25 déc. 06 à 11:46, Thomas Schwinge a écrit :
[I added the patch's author, Akim Demaille, to the cc list, as it
was not
sure if he's still reading the list.]
You're right, I'm not.
Hello!
Hi, and merry Chrismas.
On Sun, Dec 24, 2006 at 04:21:50PM -0800, Paul Eggert wrote:
Benoit Sigoure <[EMAIL PROTECTED]> writes:
http://lists.gnu.org/archive/html/automake-patches/2006-10/
msg00070.html
Sorry, I missed that one. The idea looks reasonable, but that solves
the problem for install-sh only, right? GNU 'install' still wouldn't
support -C.
This brings up the following question: if `-C' shall be used a) by
default in Autoconf's `AC_PROG_INSTALL' if available or b) if
requested
by the programmer through setting some flag, and `install-sh' supports
`-C', but the system's `install' executable doesn't (which will, as
far
as I can tell, be the case on most systems as after this quoted
patch has
been applied to `install-sh'), which of the two installation programs
shall be chosen: the native `install' for speed or `install-sh' for
feature completeness and to accommodate the programmer's request?
I agree with Paul's answer. Besides, it is IMHO high time to completely
rewrite AC_PROG_INSTALL to actually check the behavior of "install"
instead of playing dark magic with file names. It would be nice then
to be able to specify the flags one wants (e.g., -C).
Also, the updated patch proposed in
<http://lists.gnu.org/archive/html/automake-patches/2006-10/
msg00077.html>
has some coding-style components along with the substance components.
I plan to split it into two and apply the two pieces.
| +# Maybe we don't need to install the file. Use diff, not cmp,
| +# to be robust to end-of-line encoding.
| +{ if $copy_on_change &&
| + $diffprog "$dsttmp" "$dst" >/dev/null 2>&1 &&
| + new=`ls -l "$dsttmp" | awk '{print $1 ":" $3 ":" $4}'` &&
| + old=`ls -l "$dst"| awk '{print $1 ":" $3 ":" $4}'` &&
| + test x"$new" = x"$old"
| + then
| + # No need to copy, that's the same file.
| + continue
| + else :; fi; } &&
Is this ``ls -l [...] | awk [...]'' portable enough
Yes.
and is it really
needed?
Either you do that, or chmod afterwards. But install-sh behaves
quite atomically and either fully does its job, or leaves the
destination untouched.
Besides, if you just happened to have removed some read permissions,
it seems fair that all the files that depend on it no longer
compile. So the timestamps and Makefiles should not continue
as if nothing happened.
But that's a weak argument, I don't really care.
Another option I was considering was adding -I to be passed to
diff. For instance to ignore $Id$ keywords etc. But if no
real "install" support it, who cares.
| http://www.freebsd.org/cgi/man.cgi?query=install
| #v+
| [...]
| -C Copy the file. If the target file already exists
and the files
| are the same, then do not change the modification
time of the
| target. If the target's file flags and mode need
not to be
| changed, the target's inode change time is also
unchanged.
| [...]
| #v-
Regards,
Thomas
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-4.5.9: Sun Solaris 2.8 configure failure
| "Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
| > The build of coreutils-4.5.9 on Sun Solaris 2.8 failed at configure
| > time:
| >
| > % time env CC=c89 ./configure && time make all check
| > ...
| > checking whether it is possible to resort to fread on /etc/mnttab... no
| > configure: error: could not determine how to read list of mounted filesystems
|
| I looked into this issue, and the problem is that c89 rejects '#line'
| directives whose line numbers are greater than 32767. The
| coreutils-4.5.9 'configure' script contains 44223 lines, so it runs
| afoul of the problem. I think that the C standard allows this kind of
| brain damage, unfortunately.
|
| The simplest workaround is to remove this #line feature from Autoconf,
| as it's not necessary for correct operation. So I installed the
| following Autoconf patch for now. If someone can think of a better
| fix, that'd be great.
|
| 2003-03-06 Paul Eggert <[EMAIL PROTECTED]>
|
| Work around a problem noted by Nelson H. F. Beebe with coreutils
| 4.5.9: Sun c89 (Sun WorkShop 6 update 2 C 5.3 Patch 111679-08
| 2002/05/09) rejects '#line 32768 "configure"' because the line
| number overflows.
| * lib/autoconf/c.m4 (AC_LANG_SOURCE(C)): Do not generate
| #line directives.
| * lib/autoconf/lang.m4 (AC_LANG_SOURCE): Fix comment to match this.
| * doc/autoconf.texi (Generating Sources): Document this.
This is amazing :( I'm installing this:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* doc/autoconf.texi (C Compiler): `#line' portability.
From Paul Eggert and Nelson H. F. Beebe.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.725
diff -u -u -r1.725 autoconf.texi
--- doc/autoconf.texi 23 Mar 2003 10:21:43 - 1.725
+++ doc/autoconf.texi 28 Mar 2003 14:49:08 -
@@ -4985,6 +4985,13 @@
This can cause problems if you observe the output of the compiler to
detect failures. Invoking @samp{cc -c a.c -o a.o; cc -c b.c -o b.o; cc
a.o b.o -o c} solves the issue.
+
[EMAIL PROTECTED] Don't rely on correct @code{#line} support
+On Solaris 2.8, @command{c89} (Sun WorkShop 6 update 2 C 5.3 Patch
+111679-08 2002/05/09)) rejects @code{#line} directives whose line
+numbers are greater than 32767. In addition, nothing in @sc{posix}
+makes this invalid. That is the reason why Autoconf stopped issuing
[EMAIL PROTECTED] directives.
@end table
@defmac AC_PROG_CC (@ovar{compiler-search-list})
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
