GNU bug report logs -
#20733
coreutils build problem
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 4 Jun 2015 19:18:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20733 in the body.
You can then email your comments to 20733 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#20733; Package
coreutils.
(Thu, 04 Jun 2015 19:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Thu, 04 Jun 2015 19:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Let's focus on 8.23 as 8.21 is pretty old....
On 06/04/2015 09:41 AM, Michael Felt wrote:
> GEN src/coreutils.h
> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
Ah, thanks, that's a bug in the build procedure, which I have fixed by
pushing the attached patch. Please give it a try.
[0001-build-port-single_binary_prog-to-POSIX-shell.patch (text/x-patch, attachment)]
bug closed, send any further explanations to
20733 <at> debbugs.gnu.org and Paul Eggert <eggert <at> cs.ucla.edu>
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Thu, 04 Jun 2015 19:19:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 19:35:03 GMT)
Full text and
rfc822 format available.
Message #10 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[adding autoconf]
On 06/04/2015 01:17 PM, Paul Eggert wrote:
>
> On 06/04/2015 09:41 AM, Michael Felt wrote:
>> GEN src/coreutils.h
>> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>
> Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
Actually, POSIX _does_ allow for missing words between 'in' and the
terminator (; or newline) before 'do' (whether by a word that expands to
nothing, or by omission of words), requiring that the body of the for
statement is skipped in that case:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
But it is also true that older shells did not always follow this rule,
so you are indeed better off always supplying at least one word that
won't be expanded into nothingness.
Hmmm, I thought that autoconf would document it as a portability
pitfall, but I don't see it under 'for' in this link:
https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 19:36:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -195,7 +195,8 @@ check-git-hook-script-sync:
> # the selected tools when installing.
> install-exec-hook:
> $(AM_V_at)ctrans=$$(printf coreutils | sed -e "$(transform)"); \
> - for p in $(single_binary_progs); do \
> + for p in x $(single_binary_progs); do \
> + test $$p = x && continue; \
A better way to solve that is to use a shell variable:
progs='$(single_binary_progs)'; \
for p in $$progs; do
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 19:44:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/04/2015 01:35 PM, Andreas Schwab wrote:
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -195,7 +195,8 @@ check-git-hook-script-sync:
>> # the selected tools when installing.
>> install-exec-hook:
>> $(AM_V_at)ctrans=$$(printf coreutils | sed -e "$(transform)"); \
>> - for p in $(single_binary_progs); do \
>> + for p in x $(single_binary_progs); do \
>> + test $$p = x && continue; \
>
> A better way to solve that is to use a shell variable:
>
> progs='$(single_binary_progs)'; \
> for p in $$progs; do
You can also use something that expands into a no-op shell word:
for p in `` $(single_binary_progs); do
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 20:07:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Based on a report by Michael Felt, via Paul Eggert on the
coreutils list.
* doc/autoconf.texi (Limitations of Builtins) <for>: Document
problem with 'for var in ;'.
Signed-off-by: Eric Blake <eblake <at> redhat.com>
---
doc/autoconf.texi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 8c4302d..bbc9fa3 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17757,6 +17757,40 @@ Limitations of Builtins
word splitting on @samp{$@{1+"$@@"@}}; see @ref{Shell Substitutions},
item @samp{$@@}, for more.
+Posix requires support for a @command{for} loop with no list after
+@code{in}. However, Solaris @command{/bin/sh} treats that as a syntax
+error. It is possible to work around this by providing any shell word
+that expands to nothing, or by ignoring an obvious sentinel.
+
+@example
+$ @kbd{/bin/sh -c 'for a in $empty; do echo hi; done'}
+$ @kbd{/bin/sh -c 'for a in ; do echo hi; done'}
+/bin/sh: syntax error at line 1: `;' unexpected
+@end example
+
+The problem is most common in makefile fragments where a make variable
+is used as the source of a list, but sometimes results in no text. In
+that context, another common workaround is to use a shell variable
+rather than a make variable as the source of the list.
+
+@example
+$ @kbd{cat Makefile}
+list =
+bad:
+ @@for arg in $(list); do echo $$arg; done
+good:
+ @@list='$(list)'; for arg in $$list; do echo $$arg; done
+$ @kbd{make bad list='a b'}
+a
+b
+$ @kbd{make bad 2&>1 | head -n1}
+sh: syntax error at line 1: `;' unexpected
+$ @kbd{make good}
+$ @kbd{make good list='a b'}
+a
+b
+@end example
+
In Solaris @command{/bin/sh}, when the list of arguments of a
@command{for} loop starts with @emph{unquoted} tokens looking like
variable assignments, the loop is not executed on those tokens:
--
2.4.2
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 20:18:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 20733 <at> debbugs.gnu.org (full text, mbox):
On 2015-06-04 13:34 -0600, Eric Blake wrote:
> [adding autoconf]
>
> On 06/04/2015 01:17 PM, Paul Eggert wrote:
> >
> > On 06/04/2015 09:41 AM, Michael Felt wrote:
> >> GEN src/coreutils.h
> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
> >
>
> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>
> Actually, POSIX _does_ allow for missing words between 'in' and the
> terminator (; or newline) before 'do' (whether by a word that expands to
> nothing, or by omission of words), requiring that the body of the for
> statement is skipped in that case:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>
> But it is also true that older shells did not always follow this rule,
> so you are indeed better off always supplying at least one word that
> won't be expanded into nothingness.
>
> Hmmm, I thought that autoconf would document it as a portability
> pitfall, but I don't see it under 'for' in this link:
>
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
Yikes!
Some questions:
Do these problematic shells properly handle:
for arg
do
...
done
when $# is 0?
If so, can we use the following as a workaround?
set x words-that-might-expand-to-nothing; shift
for arg
do
...
done
I suppose that might be hard to do in this /particular/ case, as it
looks like the error is coming from a make rule. The Autoconf manual
quite emphatically says to avoid 'for arg; do ...' by using a newline
instead of a semicolon, a feat which is not easily done in make rules.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 20:41:02 GMT)
Full text and
rfc822 format available.
Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):
2015-06-04 14:06:03 -0600, Eric Blake:
[...]
> +$ @kbd{cat Makefile}
> +list =
> +bad:
> + @@for arg in $(list); do echo $$arg; done
> +good:
> + @@list='$(list)'; for arg in $$list; do echo $$arg; done
[...]
Another option is to use:
for arg in $${-+$(list)}; do echo $$arg; done
That's ${var+value} that expands to value if var is set. $- is
always set. $0 could also be used instead.
--
Stephane
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 20:42:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/04/2015 02:17 PM, Nick Bowler wrote:
> Do these problematic shells properly handle:
>
> for arg
> do
> ...
> done
>
> when $# is 0?
Yes; all shells do.
$ /bin/sh -c 'echo $#; for arg
do echo hi; done; echo bye'
0
bye
>
> If so, can we use the following as a workaround?
>
> set x words-that-might-expand-to-nothing; shift
> for arg
> do
> ...
> done
Not ideal, when there are shorter invocations that can do the same. And
it's not the expand-to-nothing that is a problem, it is the actual omission:
$ /bin/sh -c 'for a in ; do :; done'
/bin/sh: syntax error at line 1: `;' unexpected
$ /bin/sh -c 'for a in $nothing; do :; done'
$
so anything that expands in shell to nothing (whether $nothing, ``, or
use of a shell variable rather than a make variable) is fine; the
problem is most common in Makefiles where make variables are expanded
before the shell sees anything.
>
> I suppose that might be hard to do in this /particular/ case, as it
> looks like the error is coming from a make rule. The Autoconf manual
> quite emphatically says to avoid 'for arg; do ...' by using a newline
> instead of a semicolon, a feat which is not easily done in make rules.
The manual also has a workaround for getting a literal newline in make
rules:
nlinit=`echo 'nl="'; echo '"'`; eval "$$nlinit"
although that only gives you $nl containing newline, and you'd still
need another layer of 'eval' if you wanted to actually write the
makefile fragment to interpret the newline as a separator between the
var-name and 'do'. So yeah, it's not worth it.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 20:57:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 20733 <at> debbugs.gnu.org (full text, mbox):
On 2015-06-04 14:41 -0600, Eric Blake wrote:
> On 06/04/2015 02:17 PM, Nick Bowler wrote:
> > Do these problematic shells properly handle:
> >
> > for arg
> > do
> > ...
> > done
> >
> > when $# is 0?
>
> Yes; all shells do.
OK, good to know.
[...]
> it's not the expand-to-nothing that is a problem, it is the actual
> omission:
>
> $ /bin/sh -c 'for a in ; do :; done'
> /bin/sh: syntax error at line 1: `;' unexpected
> $ /bin/sh -c 'for a in $nothing; do :; done'
> $
Right, I see that now in the doc patch you posted. So in Autoconf this
might turn up if you generate the list with m4, but is highly unlikely
to be an issue for "pure" shell code.
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 21:00:09 GMT)
Full text and
rfc822 format available.
Message #34 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/04/2015 02:36 PM, Stephane Chazelas wrote:
> 2015-06-04 14:06:03 -0600, Eric Blake:
> [...]
>> +$ @kbd{cat Makefile}
>> +list =
>> +bad:
>> + @@for arg in $(list); do echo $$arg; done
>> +good:
>> + @@list='$(list)'; for arg in $$list; do echo $$arg; done
> [...]
>
> Another option is to use:
>
> for arg in $${-+$(list)}; do echo $$arg; done
>
>
> That's ${var+value} that expands to value if var is set. $- is
> always set. $0 could also be used instead.
Also could use $$, $? (except $? doesn't always start life set if probed
as the first thing in some shells), $# (except some shells confuse
${varOPvalue} vs. ${#var} when # is used as var). But from a readability
perspective, I don't think that playing golf for the shortest construct
is helpful, when compared to demonstrating something that is more
commonly seen in practice.
Furthermore, your suggestion mishandles a list with a bare }, whereas
mine does not. "make good list='} a'" should output $'}\na\n', not $'a}\n'.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 22:33:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/04/2015 02:59 PM, Eric Blake wrote:
>>> +good:
>>> + @@list='$(list)'; for arg in $$list; do echo $$arg; done
>> [...]
>>
>> Another option is to use:
>>
>> for arg in $${-+$(list)}; do echo $$arg; done
> Furthermore, your suggestion mishandles a list with a bare }, whereas
> mine does not. "make good list='} a'" should output $'}\na\n', not $'a}\n'.
Of course, your version has the benefit of preserving a list that
contains shell quoting (such as list = "a b" intended to produce a
single string $'a b') while mine eats it early (producing $'"a' and
$'b"'). But remember that my example is written in a context of
makefiles, where makefile variables tend to be designed to be split at
all whitespace boundaries and do not have an easy mechanism for handling
text that must have specific embedded spacing, and as such are unlikely
to require shell quoting in the first place.
Once again going to show that you have to think about each particular
problem in context (what sort of input will it be processing), rather
than blindly assuming that one formulation will be a catch-all solution.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Thu, 04 Jun 2015 23:53:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Eric Blake wrote:
> Actually, POSIX_does_ allow for missing words between 'in' and the
> terminator (; or newline) before 'do' (whether by a word that expands to
> nothing, or by omission of words), requiring that the body of the for
> statement is skipped in that case:
Ah, sorry, I was thinking of previous versions of POSIX, which required at least
one word after the 'in'. You're right, the current POSIX version doesn't
require this any more. So the Solaris sh in question is conforming to the old
POSIX standard but not to the current one.
I liked the approach with "``"; I hadn't thought of that. I used the coreutils
fix I did because other coreutils code already fixed similar for-loop problems
that way.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 08:41:02 GMT)
Full text and
rfc822 format available.
Message #43 received at submit <at> debbugs.gnu.org (full text, mbox):
2015-06-04 16:32:48 -0600, Eric Blake:
> On 06/04/2015 02:59 PM, Eric Blake wrote:
>
> >>> +good:
> >>> + @@list='$(list)'; for arg in $$list; do echo $$arg; done
> >> [...]
> >>
> >> Another option is to use:
> >>
> >> for arg in $${-+$(list)}; do echo $$arg; done
>
> > Furthermore, your suggestion mishandles a list with a bare }, whereas
> > mine does not. "make good list='} a'" should output $'}\na\n', not $'a}\n'.
>
> Of course, your version has the benefit of preserving a list that
> contains shell quoting (such as list = "a b" intended to produce a
> single string $'a b')
[...]
Not with all sh implementations though. With sh based on earlier
versions of zsh (like the sh of some old OS/X), $${-+$(list)}
would undergo split+glob.
As a solution that minimises the difference from for i in
$(list),
for i in $$empty $(list); do...
for i in `` $(list)
As already pointed out would be better.
See also:
set x $(list); shift; for i do echo "$$i"; done
Which is Bourne and POSIX (though according to
http://www.in-ulm.de/~mascheck/various/bourne_args/ not
supported by early versions of the Almquist shell (possibly
still found in the wild in some Minix systems).
--
Stephane
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 08:51:03 GMT)
Full text and
rfc822 format available.
Message #46 received at submit <at> debbugs.gnu.org (full text, mbox):
2015-06-04 16:51:49 -0700, Paul Eggert:
> Eric Blake wrote:
> >Actually, POSIX_does_ allow for missing words between 'in' and the
> >terminator (; or newline) before 'do' (whether by a word that expands to
> >nothing, or by omission of words), requiring that the body of the for
> >statement is skipped in that case:
>
> Ah, sorry, I was thinking of previous versions of POSIX, which
> required at least one word after the 'in'. You're right, the
> current POSIX version doesn't require this any more. So the Solaris
> sh in question is conforming to the old POSIX standard but not to
> the current one.
[...]
Note that the Solaris (10 and before) sh in question is not a
POSIX shell, it's still the Bourne shell which is not POSIX
conformant in many different ways (the POSIX sh spec is based on
a subset of ksh88, not the Bourne shell). In those Solaris
systems, POSIX sh is /usr/xpg4/bin/sh (based on ksh88).
Note that Solaris 11 /bin/sh is no longer the Bourne shell. It's
now based on ksh93 so is now POSIX at last.
--
Stephane
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 10:46:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
My "fear" is that autoconf has introduced this "catch-all" as I have been
running into it more frequently of late (first time was last November when
I took my first attempt at packaging gcc.)
I shall look at the patch and let you know - however, regardless of whether
it works or not - is this something that autoconf is introducing, read
changed - requiring you to make a patch. If so, while from autoconf
perspective all may be well - it is not very user-friendly. (I just do not
understand autoconf well enough to make that distinction).
Thanks for looking! and listening!!
On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake <eblake <at> redhat.com> wrote:
> [adding autoconf]
>
> On 06/04/2015 01:17 PM, Paul Eggert wrote:
> >
> > On 06/04/2015 09:41 AM, Michael Felt wrote:
> >> GEN src/coreutils.h
> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
> >
>
> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>
> Actually, POSIX _does_ allow for missing words between 'in' and the
> terminator (; or newline) before 'do' (whether by a word that expands to
> nothing, or by omission of words), requiring that the body of the for
> statement is skipped in that case:
>
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>
> But it is also true that older shells did not always follow this rule,
> so you are indeed better off always supplying at least one word that
> won't be expanded into nothingness.
>
> Hmmm, I thought that autoconf would document it as a portability
> pitfall, but I don't see it under 'for' in this link:
>
>
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 10:53:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
FYI: AIX - not Solaris - but "old-school UNIX" in both cases.
And, yes - it is /bin/sh - which is the 'Bourne shell behavior" iirc,
rather than ksh behavior, but the program is the default AIX (not solaris)
ksh (see inode #)
26 -r-xr-xr-x 15 bin bin 1457 May 14 2012 hash
58 -r-xr-sr-x 1 root security 37092 Apr 25 2014 chsh
148 lrwxrwxrwx 1 root system 28 Feb 6 13:50 fcinit.sh ->
/usr/sbin/rsct/bin/fcinit.sh
149 lrwxrwxrwx 1 root system 29 Feb 6 13:50 fcinit.csh ->
/usr/sbin/rsct/bin/fcinit.csh
263 -r-xr-s--- 1 root system 5884 Mar 7 2014 refresh
331 -r-xr-xr-x 1 bin bin 918 May 14 2012 recsh
443 -r-xr-xr-x 1 bin bin 185344 Mar 7 2014 csh
460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 Rsh
460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 bsh
540 -rwxr-xr-x 1 root system 4690 May 6 2013 c_rehash
631 lrwxrwxrwx 1 bin bin 16 Dec 20 16:21 dsh ->
/opt/csm/bin/dsh
829 -r-xr-xr-x 1 bin bin 287458 Mar 12 2013 msh
845 lrwxrwxrwx 1 root system 46 Dec 20 16:21 perfpmr.sh ->
/data/prj/labserv/perf61-2014.04.30/perfpmr.sh
907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 remsh
907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 rsh
983 lrwxrwxrwx 1 root system 17 Dec 20 16:21 tclsh ->
/usr/bin/tclsh8.4
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 psh
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 sh
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 tsh
1031 lrwxrwxrwx 1 root system 16 Dec 20 16:21 wish ->
/usr/bin/wish8.4
AIX also supports ksh93 - but that is a different executable (different
inode)
michael <at> x071:[/usr/bin]ls -li *ksh*
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93
986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93
On Fri, Jun 5, 2015 at 12:45 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
> My "fear" is that autoconf has introduced this "catch-all" as I have been
> running into it more frequently of late (first time was last November when
> I took my first attempt at packaging gcc.)
>
> I shall look at the patch and let you know - however, regardless of
> whether it works or not - is this something that autoconf is introducing,
> read changed - requiring you to make a patch. If so, while from autoconf
> perspective all may be well - it is not very user-friendly. (I just do not
> understand autoconf well enough to make that distinction).
>
> Thanks for looking! and listening!!
>
> On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake <eblake <at> redhat.com> wrote:
>
>> [adding autoconf]
>>
>> On 06/04/2015 01:17 PM, Paul Eggert wrote:
>> >
>> > On 06/04/2015 09:41 AM, Michael Felt wrote:
>> >> GEN src/coreutils.h
>> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>> >
>>
>> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>>
>> Actually, POSIX _does_ allow for missing words between 'in' and the
>> terminator (; or newline) before 'do' (whether by a word that expands to
>> nothing, or by omission of words), requiring that the body of the for
>> statement is skipped in that case:
>>
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>>
>> But it is also true that older shells did not always follow this rule,
>> so you are indeed better off always supplying at least one word that
>> won't be expanded into nothingness.
>>
>> Hmmm, I thought that autoconf would document it as a portability
>> pitfall, but I don't see it under 'for' in this link:
>>
>>
>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>
>> --
>> Eric Blake eblake redhat com +1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 11:14:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I think I still have automake 1.14 lying around, but would be nice if
automake-1.15 would have just accepted the patch :)
*Most important - the patch seems to be working!* At least I got farther...
On my "bare system" - initially NO extras installed to find 'hard', i.e.,
real dependencies.
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
GEN lib/alloca.h
GEN lib/arpa/inet.h
GEN ./src/single-binary.mk
cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
automake-1.14 --gnu Makefile
/data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
automake-1.14: not found.
WARNING: 'automake-1.14' is missing on your system.
You should only need it if you modified 'Makefile.am' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'automake' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: 1254-004 The error code from the last command is 127.
So, on my "more loaded system - x064 - (with other tools, i.e.)
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
configure.ac:35: error: version mismatch. This is Automake 1.15,
configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:35: comes from Automake 1.14.1. You should recreate
configure.ac:35: aclocal.m4 with aclocal and run automake again.
After loading automake 1.14.1 and running automake - got farther still,
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
cd . && /bin/sh ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
GEN lib/configmake.h
GEN lib/ctype.h
GEN lib/dirent.h
GEN lib/errno.h
GEN lib/fcntl.h
GEN lib/float.h
GEN lib/fnmatch.h
GEN lib/getopt.h
GEN lib/iconv.h
GEN lib/inttypes.h
GEN lib/langinfo.h
GEN lib/locale.h
GEN lib/math.h
GEN lib/netdb.h
GEN lib/selinux/selinux.h
GEN lib/selinux/context.h
GEN lib/signal.h
GEN lib/stdalign.h
GEN lib/stdint.h
GEN lib/stdio.h
GEN lib/stdlib.h
GEN lib/string.h
GEN lib/sys/ioctl.h
GEN lib/sys/resource.h
GEN lib/sys/select.h
GEN lib/sys/socket.h
GEN lib/sys/stat.h
GEN lib/sys/time.h
GEN lib/sys/types.h
GEN lib/sys/uio.h
GEN lib/sys/utsname.h
GEN lib/sys/wait.h
GEN lib/termios.h
GEN lib/time.h
GEN lib/unistd.h
GEN lib/wchar.h
GEN lib/wctype.h
GEN src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.
Shall rerun ./configure and see if the ./src directory problem is solved as
well (after automake)
p.s.
I do this packaging as root - so I always need to
# export FORCE_UNSAFE_CONFIGURE=1
Would be "more friendly" if this check could be reported earlier in
./configure rather than just before it finishes.
On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
> FYI: AIX - not Solaris - but "old-school UNIX" in both cases.
>
> And, yes - it is /bin/sh - which is the 'Bourne shell behavior" iirc,
> rather than ksh behavior, but the program is the default AIX (not solaris)
> ksh (see inode #)
>
> 26 -r-xr-xr-x 15 bin bin 1457 May 14 2012 hash
> 58 -r-xr-sr-x 1 root security 37092 Apr 25 2014 chsh
> 148 lrwxrwxrwx 1 root system 28 Feb 6 13:50 fcinit.sh ->
> /usr/sbin/rsct/bin/fcinit.sh
> 149 lrwxrwxrwx 1 root system 29 Feb 6 13:50 fcinit.csh ->
> /usr/sbin/rsct/bin/fcinit.csh
> 263 -r-xr-s--- 1 root system 5884 Mar 7 2014 refresh
> 331 -r-xr-xr-x 1 bin bin 918 May 14 2012 recsh
> 443 -r-xr-xr-x 1 bin bin 185344 Mar 7 2014 csh
> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 Rsh
> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 bsh
> 540 -rwxr-xr-x 1 root system 4690 May 6 2013 c_rehash
> 631 lrwxrwxrwx 1 bin bin 16 Dec 20 16:21 dsh ->
> /opt/csm/bin/dsh
> 829 -r-xr-xr-x 1 bin bin 287458 Mar 12 2013 msh
> 845 lrwxrwxrwx 1 root system 46 Dec 20 16:21 perfpmr.sh ->
> /data/prj/labserv/perf61-2014.04.30/perfpmr.sh
> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 remsh
> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 rsh
> 983 lrwxrwxrwx 1 root system 17 Dec 20 16:21 tclsh ->
> /usr/bin/tclsh8.4
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 psh
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 sh
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 tsh
> 1031 lrwxrwxrwx 1 root system 16 Dec 20 16:21 wish ->
> /usr/bin/wish8.4
>
> AIX also supports ksh93 - but that is a different executable (different
> inode)
>
> michael <at> x071:[/usr/bin]ls -li *ksh*
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93
> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93
>
>
>
> On Fri, Jun 5, 2015 at 12:45 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>
>> My "fear" is that autoconf has introduced this "catch-all" as I have been
>> running into it more frequently of late (first time was last November when
>> I took my first attempt at packaging gcc.)
>>
>> I shall look at the patch and let you know - however, regardless of
>> whether it works or not - is this something that autoconf is introducing,
>> read changed - requiring you to make a patch. If so, while from autoconf
>> perspective all may be well - it is not very user-friendly. (I just do not
>> understand autoconf well enough to make that distinction).
>>
>> Thanks for looking! and listening!!
>>
>> On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake <eblake <at> redhat.com> wrote:
>>
>>> [adding autoconf]
>>>
>>> On 06/04/2015 01:17 PM, Paul Eggert wrote:
>>> >
>>> > On 06/04/2015 09:41 AM, Michael Felt wrote:
>>> >> GEN src/coreutils.h
>>> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>>> >
>>>
>>> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>>>
>>> Actually, POSIX _does_ allow for missing words between 'in' and the
>>> terminator (; or newline) before 'do' (whether by a word that expands to
>>> nothing, or by omission of words), requiring that the body of the for
>>> statement is skipped in that case:
>>>
>>>
>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>>>
>>> But it is also true that older shells did not always follow this rule,
>>> so you are indeed better off always supplying at least one word that
>>> won't be expanded into nothingness.
>>>
>>> Hmmm, I thought that autoconf would document it as a portability
>>> pitfall, but I don't see it under 'for' in this link:
>>>
>>>
>>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>>
>>> --
>>> Eric Blake eblake redhat com +1-919-301-3266
>>> Libvirt virtualization library http://libvirt.org
>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 11:17:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
After rerunning ./configure --prefix=/opt I still stop at:
GEN src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.
On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
> I think I still have automake 1.14 lying around, but would be nice if
> automake-1.15 would have just accepted the patch :)
>
> *Most important - the patch seems to be working!* At least I got
> farther...
>
> On my "bare system" - initially NO extras installed to find 'hard', i.e.,
> real dependencies.
>
> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
> GEN lib/alloca.h
> GEN lib/arpa/inet.h
> GEN ./src/single-binary.mk
> cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
> automake-1.14 --gnu Makefile
> /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
> automake-1.14: not found.
> WARNING: 'automake-1.14' is missing on your system.
> You should only need it if you modified 'Makefile.am' or
> 'configure.ac' or m4 files included by 'configure.ac'.
> The 'automake' program is part of the GNU Automake package:
> <http://www.gnu.org/software/automake>
> It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> <http://www.gnu.org/software/autoconf>
> <http://www.gnu.org/software/m4/>
> <http://www.perl.org/>
> make: 1254-004 The error code from the last command is 127.
>
> So, on my "more loaded system - x064 - (with other tools, i.e.)
> root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
> configure.ac:35: error: version mismatch. This is Automake 1.15,
> configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
> configure.ac:35: comes from Automake 1.14.1. You should recreate
> configure.ac:35: aclocal.m4 with aclocal and run automake again.
>
> After loading automake 1.14.1 and running automake - got farther still,
>
> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
> cd . && /bin/sh ./config.status Makefile depfiles
> config.status: creating Makefile
> config.status: executing depfiles commands
> GEN lib/configmake.h
> GEN lib/ctype.h
> GEN lib/dirent.h
> GEN lib/errno.h
> GEN lib/fcntl.h
> GEN lib/float.h
> GEN lib/fnmatch.h
> GEN lib/getopt.h
> GEN lib/iconv.h
> GEN lib/inttypes.h
> GEN lib/langinfo.h
> GEN lib/locale.h
> GEN lib/math.h
> GEN lib/netdb.h
> GEN lib/selinux/selinux.h
> GEN lib/selinux/context.h
> GEN lib/signal.h
> GEN lib/stdalign.h
> GEN lib/stdint.h
> GEN lib/stdio.h
> GEN lib/stdlib.h
> GEN lib/string.h
> GEN lib/sys/ioctl.h
> GEN lib/sys/resource.h
> GEN lib/sys/select.h
> GEN lib/sys/socket.h
> GEN lib/sys/stat.h
> GEN lib/sys/time.h
> GEN lib/sys/types.h
> GEN lib/sys/uio.h
> GEN lib/sys/utsname.h
> GEN lib/sys/wait.h
> GEN lib/termios.h
> GEN lib/time.h
> GEN lib/unistd.h
> GEN lib/wchar.h
> GEN lib/wctype.h
> GEN src/coreutils.h
> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
> make: 1254-004 The error code from the last command is 2.
>
> Shall rerun ./configure and see if the ./src directory problem is solved
> as well (after automake)
>
> p.s.
> I do this packaging as root - so I always need to
> # export FORCE_UNSAFE_CONFIGURE=1
>
> Would be "more friendly" if this check could be reported earlier in
> ./configure rather than just before it finishes.
>
> On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>
>> FYI: AIX - not Solaris - but "old-school UNIX" in both cases.
>>
>> And, yes - it is /bin/sh - which is the 'Bourne shell behavior" iirc,
>> rather than ksh behavior, but the program is the default AIX (not solaris)
>> ksh (see inode #)
>>
>> 26 -r-xr-xr-x 15 bin bin 1457 May 14 2012 hash
>> 58 -r-xr-sr-x 1 root security 37092 Apr 25 2014 chsh
>> 148 lrwxrwxrwx 1 root system 28 Feb 6 13:50 fcinit.sh ->
>> /usr/sbin/rsct/bin/fcinit.sh
>> 149 lrwxrwxrwx 1 root system 29 Feb 6 13:50 fcinit.csh ->
>> /usr/sbin/rsct/bin/fcinit.csh
>> 263 -r-xr-s--- 1 root system 5884 Mar 7 2014 refresh
>> 331 -r-xr-xr-x 1 bin bin 918 May 14 2012 recsh
>> 443 -r-xr-xr-x 1 bin bin 185344 Mar 7 2014 csh
>> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 Rsh
>> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 bsh
>> 540 -rwxr-xr-x 1 root system 4690 May 6 2013 c_rehash
>> 631 lrwxrwxrwx 1 bin bin 16 Dec 20 16:21 dsh ->
>> /opt/csm/bin/dsh
>> 829 -r-xr-xr-x 1 bin bin 287458 Mar 12 2013 msh
>> 845 lrwxrwxrwx 1 root system 46 Dec 20 16:21 perfpmr.sh ->
>> /data/prj/labserv/perf61-2014.04.30/perfpmr.sh
>> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 remsh
>> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 rsh
>> 983 lrwxrwxrwx 1 root system 17 Dec 20 16:21 tclsh ->
>> /usr/bin/tclsh8.4
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 psh
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 sh
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 tsh
>> 1031 lrwxrwxrwx 1 root system 16 Dec 20 16:21 wish ->
>> /usr/bin/wish8.4
>>
>> AIX also supports ksh93 - but that is a different executable (different
>> inode)
>>
>> michael <at> x071:[/usr/bin]ls -li *ksh*
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
>> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93
>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
>> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93
>>
>>
>>
>> On Fri, Jun 5, 2015 at 12:45 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>>
>>> My "fear" is that autoconf has introduced this "catch-all" as I have
>>> been running into it more frequently of late (first time was last November
>>> when I took my first attempt at packaging gcc.)
>>>
>>> I shall look at the patch and let you know - however, regardless of
>>> whether it works or not - is this something that autoconf is introducing,
>>> read changed - requiring you to make a patch. If so, while from autoconf
>>> perspective all may be well - it is not very user-friendly. (I just do not
>>> understand autoconf well enough to make that distinction).
>>>
>>> Thanks for looking! and listening!!
>>>
>>> On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake <eblake <at> redhat.com> wrote:
>>>
>>>> [adding autoconf]
>>>>
>>>> On 06/04/2015 01:17 PM, Paul Eggert wrote:
>>>> >
>>>> > On 06/04/2015 09:41 AM, Michael Felt wrote:
>>>> >> GEN src/coreutils.h
>>>> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>>>> >
>>>>
>>>> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>>>>
>>>> Actually, POSIX _does_ allow for missing words between 'in' and the
>>>> terminator (; or newline) before 'do' (whether by a word that expands to
>>>> nothing, or by omission of words), requiring that the body of the for
>>>> statement is skipped in that case:
>>>>
>>>>
>>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>>>>
>>>> But it is also true that older shells did not always follow this rule,
>>>> so you are indeed better off always supplying at least one word that
>>>> won't be expanded into nothingness.
>>>>
>>>> Hmmm, I thought that autoconf would document it as a portability
>>>> pitfall, but I don't see it under 'for' in this link:
>>>>
>>>>
>>>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>>>
>>>> --
>>>> Eric Blake eblake redhat com +1-919-301-3266
>>>> Libvirt virtualization library http://libvirt.org
>>>>
>>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 11:21:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Actually, looking at this more closely - before make did not do anything in
./lib initially - now it starts there, and it still comes to a halt with
GEN src/coreutils.h
Funny how the lib stuff can be generated without src/coreutils.h - is that
by design? I shall go back two steps (remove all, unpack, patch, automake,
and see where/how things go).
Michael
On Fri, Jun 5, 2015 at 1:16 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
> After rerunning ./configure --prefix=/opt I still stop at:
>
> GEN src/coreutils.h
> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
> make: 1254-004 The error code from the last command is 2.
>
>
>
> On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>
>> I think I still have automake 1.14 lying around, but would be nice if
>> automake-1.15 would have just accepted the patch :)
>>
>> *Most important - the patch seems to be working!* At least I got
>> farther...
>>
>> On my "bare system" - initially NO extras installed to find 'hard', i.e.,
>> real dependencies.
>>
>> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
>> GEN lib/alloca.h
>> GEN lib/arpa/inet.h
>> GEN ./src/single-binary.mk
>> cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
>> automake-1.14 --gnu Makefile
>> /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
>> automake-1.14: not found.
>> WARNING: 'automake-1.14' is missing on your system.
>> You should only need it if you modified 'Makefile.am' or
>> 'configure.ac' or m4 files included by 'configure.ac'.
>> The 'automake' program is part of the GNU Automake package:
>> <http://www.gnu.org/software/automake>
>> It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>> <http://www.gnu.org/software/autoconf>
>> <http://www.gnu.org/software/m4/>
>> <http://www.perl.org/>
>> make: 1254-004 The error code from the last command is 127.
>>
>> So, on my "more loaded system - x064 - (with other tools, i.e.)
>> root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
>> configure.ac:35: error: version mismatch. This is Automake 1.15,
>> configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
>> configure.ac:35: comes from Automake 1.14.1. You should recreate
>> configure.ac:35: aclocal.m4 with aclocal and run automake again.
>>
>> After loading automake 1.14.1 and running automake - got farther still,
>>
>> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
>> cd . && /bin/sh ./config.status Makefile depfiles
>> config.status: creating Makefile
>> config.status: executing depfiles commands
>> GEN lib/configmake.h
>> GEN lib/ctype.h
>> GEN lib/dirent.h
>> GEN lib/errno.h
>> GEN lib/fcntl.h
>> GEN lib/float.h
>> GEN lib/fnmatch.h
>> GEN lib/getopt.h
>> GEN lib/iconv.h
>> GEN lib/inttypes.h
>> GEN lib/langinfo.h
>> GEN lib/locale.h
>> GEN lib/math.h
>> GEN lib/netdb.h
>> GEN lib/selinux/selinux.h
>> GEN lib/selinux/context.h
>> GEN lib/signal.h
>> GEN lib/stdalign.h
>> GEN lib/stdint.h
>> GEN lib/stdio.h
>> GEN lib/stdlib.h
>> GEN lib/string.h
>> GEN lib/sys/ioctl.h
>> GEN lib/sys/resource.h
>> GEN lib/sys/select.h
>> GEN lib/sys/socket.h
>> GEN lib/sys/stat.h
>> GEN lib/sys/time.h
>> GEN lib/sys/types.h
>> GEN lib/sys/uio.h
>> GEN lib/sys/utsname.h
>> GEN lib/sys/wait.h
>> GEN lib/termios.h
>> GEN lib/time.h
>> GEN lib/unistd.h
>> GEN lib/wchar.h
>> GEN lib/wctype.h
>> GEN src/coreutils.h
>> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>> make: 1254-004 The error code from the last command is 2.
>>
>> Shall rerun ./configure and see if the ./src directory problem is solved
>> as well (after automake)
>>
>> p.s.
>> I do this packaging as root - so I always need to
>> # export FORCE_UNSAFE_CONFIGURE=1
>>
>> Would be "more friendly" if this check could be reported earlier in
>> ./configure rather than just before it finishes.
>>
>> On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>>
>>> FYI: AIX - not Solaris - but "old-school UNIX" in both cases.
>>>
>>> And, yes - it is /bin/sh - which is the 'Bourne shell behavior" iirc,
>>> rather than ksh behavior, but the program is the default AIX (not solaris)
>>> ksh (see inode #)
>>>
>>> 26 -r-xr-xr-x 15 bin bin 1457 May 14 2012 hash
>>> 58 -r-xr-sr-x 1 root security 37092 Apr 25 2014 chsh
>>> 148 lrwxrwxrwx 1 root system 28 Feb 6 13:50 fcinit.sh ->
>>> /usr/sbin/rsct/bin/fcinit.sh
>>> 149 lrwxrwxrwx 1 root system 29 Feb 6 13:50 fcinit.csh ->
>>> /usr/sbin/rsct/bin/fcinit.csh
>>> 263 -r-xr-s--- 1 root system 5884 Mar 7 2014 refresh
>>> 331 -r-xr-xr-x 1 bin bin 918 May 14 2012 recsh
>>> 443 -r-xr-xr-x 1 bin bin 185344 Mar 7 2014 csh
>>> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 Rsh
>>> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 bsh
>>> 540 -rwxr-xr-x 1 root system 4690 May 6 2013 c_rehash
>>> 631 lrwxrwxrwx 1 bin bin 16 Dec 20 16:21 dsh ->
>>> /opt/csm/bin/dsh
>>> 829 -r-xr-xr-x 1 bin bin 287458 Mar 12 2013 msh
>>> 845 lrwxrwxrwx 1 root system 46 Dec 20 16:21 perfpmr.sh ->
>>> /data/prj/labserv/perf61-2014.04.30/perfpmr.sh
>>> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 remsh
>>> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 rsh
>>> 983 lrwxrwxrwx 1 root system 17 Dec 20 16:21 tclsh ->
>>> /usr/bin/tclsh8.4
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 psh
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 sh
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 tsh
>>> 1031 lrwxrwxrwx 1 root system 16 Dec 20 16:21 wish ->
>>> /usr/bin/wish8.4
>>>
>>> AIX also supports ksh93 - but that is a different executable (different
>>> inode)
>>>
>>> michael <at> x071:[/usr/bin]ls -li *ksh*
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
>>> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93
>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
>>> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93
>>>
>>>
>>>
>>> On Fri, Jun 5, 2015 at 12:45 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>>>
>>>> My "fear" is that autoconf has introduced this "catch-all" as I have
>>>> been running into it more frequently of late (first time was last November
>>>> when I took my first attempt at packaging gcc.)
>>>>
>>>> I shall look at the patch and let you know - however, regardless of
>>>> whether it works or not - is this something that autoconf is introducing,
>>>> read changed - requiring you to make a patch. If so, while from autoconf
>>>> perspective all may be well - it is not very user-friendly. (I just do not
>>>> understand autoconf well enough to make that distinction).
>>>>
>>>> Thanks for looking! and listening!!
>>>>
>>>> On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake <eblake <at> redhat.com> wrote:
>>>>
>>>>> [adding autoconf]
>>>>>
>>>>> On 06/04/2015 01:17 PM, Paul Eggert wrote:
>>>>> >
>>>>> > On 06/04/2015 09:41 AM, Michael Felt wrote:
>>>>> >> GEN src/coreutils.h
>>>>> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>>>>> >
>>>>>
>>>>> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>>>>>
>>>>> Actually, POSIX _does_ allow for missing words between 'in' and the
>>>>> terminator (; or newline) before 'do' (whether by a word that expands
>>>>> to
>>>>> nothing, or by omission of words), requiring that the body of the for
>>>>> statement is skipped in that case:
>>>>>
>>>>>
>>>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>>>>>
>>>>> But it is also true that older shells did not always follow this rule,
>>>>> so you are indeed better off always supplying at least one word that
>>>>> won't be expanded into nothingness.
>>>>>
>>>>> Hmmm, I thought that autoconf would document it as a portability
>>>>> pitfall, but I don't see it under 'for' in this link:
>>>>>
>>>>>
>>>>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>>>>
>>>>> --
>>>>> Eric Blake eblake redhat com +1-919-301-3266
>>>>> Libvirt virtualization library http://libvirt.org
>>>>>
>>>>>
>>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 11:34:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
As I said before - I do not really know the ins and outs of autoconf and
automake - so I shall only summarize my steps:
On my "download" server... (/data/prj is an NFS mount shared by all servers)
michael <at> x071:[/data/prj/gnu/coreutils]xz -dc *23*xz | tar xf -
michael <at> x071:[/data/prj/gnu/coreutils]cd *23
michael <at> x071:[/data/prj/gnu/coreutils/coreutils-8.23]cat ../*patch | patch
-p1
(Stripping trailing CRs from patch.)
patching file Makefile.am
Hunk #1 succeeded at 190 (offset -5 lines).
(Stripping trailing CRs from patch.)
patching file src/local.mk
Hunk #1 succeeded at 420 (offset -7 lines).
Hunk #2 succeeded at 429 (offset -7 lines).
Hunk #3 succeeded at 439 (offset -7 lines).
michael <at> x071:[/data/prj/gnu/coreutils/coreutils-8.23]
On my AIX 5.3 - "tooled" server
root <at> x064:[/data/prj/gnu/coreutils]cd -
/data/prj/gnu/coreutils/coreutils-8.23
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
On my bare "build server"
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]./configure --prefix=/opt
...
checking for msgmerge... no
checking for CFPreferencesCopyAppValue... (cached) no
checking for CFLocaleCopyCurrent... (cached) no
checking for GNU gettext in libc... no
checking for iconv... (cached) yes
checking for working iconv... (cached) no
checking for GNU gettext in libintl... no
checking whether to use NLS... no
checking for a traditional french locale... (cached) none
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating gnulib-tests/Makefile
config.status: creating lib/config.h
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing man/dynamic-deps.mk commands
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
GEN lib/alloca.h
GEN lib/c++defs.h
GEN lib/warn-on-use.h
GEN lib/arg-nonnull.h
GEN lib/arpa/inet.h
GEN ./src/single-binary.mk
cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
automake-1.14 --gnu Makefile
/data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
automake-1.14: not found.
WARNING: 'automake-1.14' is missing on your system.
You should only need it if you modified 'Makefile.am' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'automake' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: 1254-004 The error code from the last command is 127.
Stop.
Back on "tooled server"
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]
Back on "build server"
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
cd . && /bin/sh ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
GEN lib/configmake.h
GEN lib/ctype.h
GEN lib/dirent.h
GEN lib/errno.h
GEN lib/fcntl.h
GEN lib/float.h
GEN lib/fnmatch.h
GEN lib/getopt.h
GEN lib/iconv.h
GEN lib/inttypes.h
GEN lib/langinfo.h
GEN lib/locale.h
GEN lib/math.h
GEN lib/netdb.h
GEN lib/unused-parameter.h
GEN lib/selinux/selinux.h
GEN lib/selinux/context.h
GEN lib/signal.h
GEN lib/stdalign.h
GEN lib/stdint.h
GEN lib/stdio.h
GEN lib/stdlib.h
GEN lib/string.h
GEN lib/sys/ioctl.h
GEN lib/sys/resource.h
GEN lib/sys/select.h
GEN lib/sys/socket.h
GEN lib/sys/stat.h
GEN lib/sys/time.h
GEN lib/sys/types.h
GEN lib/sys/uio.h
GEN lib/sys/utsname.h
GEN lib/sys/wait.h
GEN lib/termios.h
GEN lib/time.h
GEN lib/unistd.h
GEN lib/unistr.h
GEN lib/unitypes.h
GEN lib/uniwidth.h
GEN lib/wchar.h
GEN lib/wctype.h
GEN src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.
Stop.
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]
And, it feels as if I am back where I first started - GEN of
src/coreutils.h is unhappy.
Thank you for your consideration.
On Fri, Jun 5, 2015 at 1:20 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
> Actually, looking at this more closely - before make did not do anything
> in ./lib initially - now it starts there, and it still comes to a halt with
> GEN src/coreutils.h
>
> Funny how the lib stuff can be generated without src/coreutils.h - is that
> by design? I shall go back two steps (remove all, unpack, patch, automake,
> and see where/how things go).
>
> Michael
>
> On Fri, Jun 5, 2015 at 1:16 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>
>> After rerunning ./configure --prefix=/opt I still stop at:
>>
>> GEN src/coreutils.h
>> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>> make: 1254-004 The error code from the last command is 2.
>>
>>
>>
>> On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>>
>>> I think I still have automake 1.14 lying around, but would be nice if
>>> automake-1.15 would have just accepted the patch :)
>>>
>>> *Most important - the patch seems to be working!* At least I got
>>> farther...
>>>
>>> On my "bare system" - initially NO extras installed to find 'hard',
>>> i.e., real dependencies.
>>>
>>> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
>>> GEN lib/alloca.h
>>> GEN lib/arpa/inet.h
>>> GEN ./src/single-binary.mk
>>> cd . && /bin/sh
>>> /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing automake-1.14
>>> --gnu Makefile
>>> /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
>>> automake-1.14: not found.
>>> WARNING: 'automake-1.14' is missing on your system.
>>> You should only need it if you modified 'Makefile.am' or
>>> 'configure.ac' or m4 files included by 'configure.ac'.
>>> The 'automake' program is part of the GNU Automake package:
>>> <http://www.gnu.org/software/automake>
>>> It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>> <http://www.gnu.org/software/autoconf>
>>> <http://www.gnu.org/software/m4/>
>>> <http://www.perl.org/>
>>> make: 1254-004 The error code from the last command is 127.
>>>
>>> So, on my "more loaded system - x064 - (with other tools, i.e.)
>>> root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
>>> configure.ac:35: error: version mismatch. This is Automake 1.15,
>>> configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
>>> configure.ac:35: comes from Automake 1.14.1. You should recreate
>>> configure.ac:35: aclocal.m4 with aclocal and run automake again.
>>>
>>> After loading automake 1.14.1 and running automake - got farther still,
>>>
>>> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
>>> cd . && /bin/sh ./config.status Makefile depfiles
>>> config.status: creating Makefile
>>> config.status: executing depfiles commands
>>> GEN lib/configmake.h
>>> GEN lib/ctype.h
>>> GEN lib/dirent.h
>>> GEN lib/errno.h
>>> GEN lib/fcntl.h
>>> GEN lib/float.h
>>> GEN lib/fnmatch.h
>>> GEN lib/getopt.h
>>> GEN lib/iconv.h
>>> GEN lib/inttypes.h
>>> GEN lib/langinfo.h
>>> GEN lib/locale.h
>>> GEN lib/math.h
>>> GEN lib/netdb.h
>>> GEN lib/selinux/selinux.h
>>> GEN lib/selinux/context.h
>>> GEN lib/signal.h
>>> GEN lib/stdalign.h
>>> GEN lib/stdint.h
>>> GEN lib/stdio.h
>>> GEN lib/stdlib.h
>>> GEN lib/string.h
>>> GEN lib/sys/ioctl.h
>>> GEN lib/sys/resource.h
>>> GEN lib/sys/select.h
>>> GEN lib/sys/socket.h
>>> GEN lib/sys/stat.h
>>> GEN lib/sys/time.h
>>> GEN lib/sys/types.h
>>> GEN lib/sys/uio.h
>>> GEN lib/sys/utsname.h
>>> GEN lib/sys/wait.h
>>> GEN lib/termios.h
>>> GEN lib/time.h
>>> GEN lib/unistd.h
>>> GEN lib/wchar.h
>>> GEN lib/wctype.h
>>> GEN src/coreutils.h
>>> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>>> make: 1254-004 The error code from the last command is 2.
>>>
>>> Shall rerun ./configure and see if the ./src directory problem is solved
>>> as well (after automake)
>>>
>>> p.s.
>>> I do this packaging as root - so I always need to
>>> # export FORCE_UNSAFE_CONFIGURE=1
>>>
>>> Would be "more friendly" if this check could be reported earlier in
>>> ./configure rather than just before it finishes.
>>>
>>> On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>>>
>>>> FYI: AIX - not Solaris - but "old-school UNIX" in both cases.
>>>>
>>>> And, yes - it is /bin/sh - which is the 'Bourne shell behavior" iirc,
>>>> rather than ksh behavior, but the program is the default AIX (not solaris)
>>>> ksh (see inode #)
>>>>
>>>> 26 -r-xr-xr-x 15 bin bin 1457 May 14 2012 hash
>>>> 58 -r-xr-sr-x 1 root security 37092 Apr 25 2014 chsh
>>>> 148 lrwxrwxrwx 1 root system 28 Feb 6 13:50 fcinit.sh ->
>>>> /usr/sbin/rsct/bin/fcinit.sh
>>>> 149 lrwxrwxrwx 1 root system 29 Feb 6 13:50 fcinit.csh ->
>>>> /usr/sbin/rsct/bin/fcinit.csh
>>>> 263 -r-xr-s--- 1 root system 5884 Mar 7 2014 refresh
>>>> 331 -r-xr-xr-x 1 bin bin 918 May 14 2012 recsh
>>>> 443 -r-xr-xr-x 1 bin bin 185344 Mar 7 2014 csh
>>>> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 Rsh
>>>> 460 -r-xr-xr-x 2 bin bin 2900986 Aug 20 2014 bsh
>>>> 540 -rwxr-xr-x 1 root system 4690 May 6 2013 c_rehash
>>>> 631 lrwxrwxrwx 1 bin bin 16 Dec 20 16:21 dsh ->
>>>> /opt/csm/bin/dsh
>>>> 829 -r-xr-xr-x 1 bin bin 287458 Mar 12 2013 msh
>>>> 845 lrwxrwxrwx 1 root system 46 Dec 20 16:21 perfpmr.sh ->
>>>> /data/prj/labserv/perf61-2014.04.30/perfpmr.sh
>>>> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 remsh
>>>> 907 -r-sr-xr-x 2 root system 28270 Mar 8 2014 rsh
>>>> 983 lrwxrwxrwx 1 root system 17 Dec 20 16:21 tclsh ->
>>>> /usr/bin/tclsh8.4
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 psh
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 sh
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 tsh
>>>> 1031 lrwxrwxrwx 1 root system 16 Dec 20 16:21 wish ->
>>>> /usr/bin/wish8.4
>>>>
>>>> AIX also supports ksh93 - but that is a different executable (different
>>>> inode)
>>>>
>>>> michael <at> x071:[/usr/bin]ls -li *ksh*
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh
>>>> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93
>>>> 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh
>>>> 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93
>>>>
>>>>
>>>>
>>>> On Fri, Jun 5, 2015 at 12:45 PM, Michael Felt <mamfelt <at> gmail.com>
>>>> wrote:
>>>>
>>>>> My "fear" is that autoconf has introduced this "catch-all" as I have
>>>>> been running into it more frequently of late (first time was last November
>>>>> when I took my first attempt at packaging gcc.)
>>>>>
>>>>> I shall look at the patch and let you know - however, regardless of
>>>>> whether it works or not - is this something that autoconf is introducing,
>>>>> read changed - requiring you to make a patch. If so, while from autoconf
>>>>> perspective all may be well - it is not very user-friendly. (I just do not
>>>>> understand autoconf well enough to make that distinction).
>>>>>
>>>>> Thanks for looking! and listening!!
>>>>>
>>>>> On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake <eblake <at> redhat.com> wrote:
>>>>>
>>>>>> [adding autoconf]
>>>>>>
>>>>>> On 06/04/2015 01:17 PM, Paul Eggert wrote:
>>>>>> >
>>>>>> > On 06/04/2015 09:41 AM, Michael Felt wrote:
>>>>>> >> GEN src/coreutils.h
>>>>>> >> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>>>>>> >
>>>>>>
>>>>>> > Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
>>>>>>
>>>>>> Actually, POSIX _does_ allow for missing words between 'in' and the
>>>>>> terminator (; or newline) before 'do' (whether by a word that expands
>>>>>> to
>>>>>> nothing, or by omission of words), requiring that the body of the for
>>>>>> statement is skipped in that case:
>>>>>>
>>>>>>
>>>>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
>>>>>>
>>>>>> But it is also true that older shells did not always follow this rule,
>>>>>> so you are indeed better off always supplying at least one word that
>>>>>> won't be expanded into nothingness.
>>>>>>
>>>>>> Hmmm, I thought that autoconf would document it as a portability
>>>>>> pitfall, but I don't see it under 'for' in this link:
>>>>>>
>>>>>>
>>>>>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>>>>>
>>>>>> --
>>>>>> Eric Blake eblake redhat com +1-919-301-3266
>>>>>> Libvirt virtualization library http://libvirt.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 11:52:01 GMT)
Full text and
rfc822 format available.
Message #67 received at submit <at> debbugs.gnu.org (full text, mbox):
2015-06-05 09:43:10 +0100, Stephane Chazelas:
> 2015-06-04 16:51:49 -0700, Paul Eggert:
[...]
> > Ah, sorry, I was thinking of previous versions of POSIX, which
> > required at least one word after the 'in'. You're right, the
> > current POSIX version doesn't require this any more. So the Solaris
> > sh in question is conforming to the old POSIX standard but not to
> > the current one.
> [...]
>
> Note that the Solaris (10 and before) sh in question is not a
> POSIX shell, it's still the Bourne shell which is not POSIX
> conformant in many different ways (the POSIX sh spec is based on
> a subset of ksh88, not the Bourne shell). In those Solaris
> systems, POSIX sh is /usr/xpg4/bin/sh (based on ksh88).
[...]
Well, the /usr/xpg4/bin/sh of Solaris 10 (based on ksh88i)
doesn't support "for i in; do" either. That "sh" would be
conforming to the older version of POSIX as you said.
--
Stephane
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 13:06:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/05/2015 04:45 AM, Michael Felt wrote:
[we tend to avoid top-posting on technical lists, as it makes it harder
to follow the flow of the message]
> My "fear" is that autoconf has introduced this "catch-all" as I have been
> running into it more frequently of late (first time was last November when
> I took my first attempt at packaging gcc.)
>
Paul's patch was specific to a coreutils file. So far, I have not seen
any evidence of autoconf introducing 'for x in ;' anywhere in configure.
If you are seeing the same problem in multiple packages, so far it is
because each package has made a similar mistake in their local
configuration files.
> I shall look at the patch and let you know - however, regardless of whether
> it works or not - is this something that autoconf is introducing, read
> changed - requiring you to make a patch. If so, while from autoconf
> perspective all may be well - it is not very user-friendly. (I just do not
> understand autoconf well enough to make that distinction).
If the syntax error is in autoconf.ac or in Makefile.am, then it is the
package that wrote the file at fault. If the syntax error is not in
anything the package provides, but appears in the generated configure
file, then it is more likely to be in automake or autoconf.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 13:09:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/05/2015 05:13 AM, Michael Felt wrote:
> I think I still have automake 1.14 lying around, but would be nice if
> automake-1.15 would have just accepted the patch :)
>
> *Most important - the patch seems to be working!* At least I got farther...
>
> On my "bare system" - initially NO extras installed to find 'hard', i.e.,
> real dependencies.
>
> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
> GEN lib/alloca.h
> GEN lib/arpa/inet.h
> GEN ./src/single-binary.mk
> cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
> automake-1.14 --gnu Makefile
> /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
> automake-1.14: not found.
> WARNING: 'automake-1.14' is missing on your system.
That says you are doing an incremental build, but have updated automake
in the meantime. Do 'autoreconf -f' to pick up the new automake version
into your generated Makefile.in files, and it should fix this issue.
A fresh checkout rather than an incremental build would also work.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 13:14:03 GMT)
Full text and
rfc822 format available.
Message #76 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
an incremental build - isn't that what applying a patch to an official
release is. A fresh checkout is 'all patches' and difficult to replicate,
once another patch is applied.
Or I am just too old of a dog and having trouble learning this new trick :)
As far as above is concerned - I had automake 1.15 installed. I removed it
and installed automake-1.14.1 and the 'complaint' went away when I ran
automake.
On Fri, Jun 5, 2015 at 3:08 PM, Eric Blake <eblake <at> redhat.com> wrote:
> On 06/05/2015 05:13 AM, Michael Felt wrote:
> > I think I still have automake 1.14 lying around, but would be nice if
> > automake-1.15 would have just accepted the patch :)
> >
> > *Most important - the patch seems to be working!* At least I got
> farther...
> >
> > On my "bare system" - initially NO extras installed to find 'hard', i.e.,
> > real dependencies.
> >
> > root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
> > GEN lib/alloca.h
> > GEN lib/arpa/inet.h
> > GEN ./src/single-binary.mk
> > cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
> > automake-1.14 --gnu Makefile
> > /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
> > automake-1.14: not found.
> > WARNING: 'automake-1.14' is missing on your system.
>
> That says you are doing an incremental build, but have updated automake
> in the meantime. Do 'autoreconf -f' to pick up the new automake version
> into your generated Makefile.in files, and it should fix this issue.
>
> A fresh checkout rather than an incremental build would also work.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 13:16:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is reassuring. Thank you for the reply.
On Fri, Jun 5, 2015 at 3:05 PM, Eric Blake <eblake <at> redhat.com> wrote:
> On 06/05/2015 04:45 AM, Michael Felt wrote:
>
> [we tend to avoid top-posting on technical lists, as it makes it harder
> to follow the flow of the message]
>
> > My "fear" is that autoconf has introduced this "catch-all" as I have been
> > running into it more frequently of late (first time was last November
> when
> > I took my first attempt at packaging gcc.)
> >
>
> Paul's patch was specific to a coreutils file. So far, I have not seen
> any evidence of autoconf introducing 'for x in ;' anywhere in configure.
> If you are seeing the same problem in multiple packages, so far it is
> because each package has made a similar mistake in their local
> configuration files.
>
> > I shall look at the patch and let you know - however, regardless of
> whether
> > it works or not - is this something that autoconf is introducing, read
> > changed - requiring you to make a patch. If so, while from autoconf
> > perspective all may be well - it is not very user-friendly. (I just do
> not
> > understand autoconf well enough to make that distinction).
>
> If the syntax error is in autoconf.ac or in Makefile.am, then it is the
> package that wrote the file at fault. If the syntax error is not in
> anything the package provides, but appears in the generated configure
> file, then it is more likely to be in automake or autoconf.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 14:08:03 GMT)
Full text and
rfc822 format available.
Message #82 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Michael Felt wrote:
> GEN src/coreutils.h
> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
> make: 1254-004 The error code from the last command is 2.
This looks like the coreutils patch wasn't properly propagated somehow. What's
the output of 'make V=1'?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 14:10:04 GMT)
Full text and
rfc822 format available.
Message #85 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
rm -f src/coreutils.h
for prog in ; do prog=`basename
$prog`; main=`echo $prog | tr '['
'_'`; echo "SINGLE_BINARY_PROGRAM(\"$prog\",
$main)"; done | sort > src/coreutils.ht
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.
Stop.
root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]
On Fri, Jun 5, 2015 at 4:07 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Michael Felt wrote:
>
>> GEN src/coreutils.h
>> /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
>> make: 1254-004 The error code from the last command is 2.
>>
>
> This looks like the coreutils patch wasn't properly propagated somehow.
> What's the output of 'make V=1'?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 14:25:03 GMT)
Full text and
rfc822 format available.
Message #88 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Michael Felt wrote:
> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
> rm -f src/coreutils.h
> for prog in ; do prog=`basenam
Yes, it looks like something went wrong in your build process and you're using a
Makefile.in generated from unpatched sources. I just now built a distribution
tarball from the bleeding edge sources, a tarball that shouldn't have this
problem; can you give it a try? It's here:
http://www.cs.ucla.edu/~eggert/coreutils-8.23.209-7eaf8.tar.xz
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 14:31:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/05/2015 08:09 AM, Michael Felt wrote:
> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
> rm -f src/coreutils.h
> for prog in ; do prog=`basename
That's missing the changes; are you sure you reran both 'automake' and
'config.status' to regenerate your Makefile with the updated source?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 14:33:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Better, but...
GEN lib/wctype.h
GEN src/coreutils.h
GEN src/version.c
GEN src/version.h
make all-recursive
Making all in po
Target "all" is up to date.
Making all in .
CC lib/copy-acl.o
CC lib/set-acl.o
CC lib/acl-errno-valid.o
CC lib/acl-internal.o
CC lib/get-permissions.o
"lib/get-permissions.c", line 258.5: 1506-045 (S) Undeclared identifier ret.
"lib/get-permissions.c", line 260.20: 1506-280 (W) Function argument
assignment between types "char*" and "const char*" is not allowed.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
On Fri, Jun 5, 2015 at 4:24 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Michael Felt wrote:
>
>> root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
>> rm -f src/coreutils.h
>> for prog in ; do prog=`basenam
>>
>
> Yes, it looks like something went wrong in your build process and you're
> using a Makefile.in generated from unpatched sources. I just now built a
> distribution tarball from the bleeding edge sources, a tarball that
> shouldn't have this problem; can you give it a try? It's here:
>
> http://www.cs.ucla.edu/~eggert/coreutils-8.23.209-7eaf8.tar.xz
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 14:35:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I did not run config.status - this dog missed that part of the trick!
On Fri, Jun 5, 2015 at 4:30 PM, Eric Blake <eblake <at> redhat.com> wrote:
> On 06/05/2015 08:09 AM, Michael Felt wrote:
> > root <at> x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
> > rm -f src/coreutils.h
> > for prog in ; do prog=`basename
>
> That's missing the changes; are you sure you reran both 'automake' and
> 'config.status' to regenerate your Makefile with the updated source?
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 15:30:06 GMT)
Full text and
rfc822 format available.
Message #100 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Felt wrote:
> "lib/get-permissions.c", line 258.5: 1506-045 (S) Undeclared identifier ret.
> "lib/get-permissions.c", line 260.20: 1506-280 (W) Function argument
> assignment between types "char*" and "const char*" is not allowed.
> make: 1254-004 The error code from the last command is 1.
That's a bug recently introduced into gnulib, and it's the sort of fun one gets
on the bleeding edge. I installed the attached patch and will cc: this to
bug-gnulib. Now please try:
http://www.cs.ucla.edu/~eggert/coreutils-8.23.211-b1d1a.tar.xz
[gnulib.diff (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 16:03:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
CCLD src/make-prime-list
CC src/src_libstdbuf_so-libstdbuf.o
"src/libstdbuf.c", line 129.27: 1506-943 (W) Attribute "constructor" is not
supported on the target platform and is ignored.
CCLD src/libstdbuf.so
ld: 0706-005 Cannot find or open file: PIC
ld:fopen(): A file or directory in the path name does not exist.
ld: 0706-012 The -h flag is not recognized.
ld: 0706-012 The -a flag is not recognized.
make: 1254-004 The error code from the last command is 255.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
amd then make V=1
Making all in .
cc -qlanglvl=extc89 -qlanglvl=extc99 -fPIC -g -shared -o
src/libstdbuf.so src/src_libstdbuf_so-libstdbuf.o
ld: 0706-005 Cannot find or open file: PIC
ld:fopen(): A file or directory in the path name does not exist.
ld: 0706-012 The -h flag is not recognized.
ld: 0706-012 The -a flag is not recognized.
make: 1254-004 The error code from the last command is 255.
On Fri, Jun 5, 2015 at 5:29 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Michael Felt wrote:
>
>> "lib/get-permissions.c", line 258.5: 1506-045 (S) Undeclared identifier
>> ret.
>> "lib/get-permissions.c", line 260.20: 1506-280 (W) Function argument
>> assignment between types "char*" and "const char*" is not allowed.
>> make: 1254-004 The error code from the last command is 1.
>>
>
> That's a bug recently introduced into gnulib, and it's the sort of fun one
> gets on the bleeding edge. I installed the attached patch and will cc:
> this to bug-gnulib. Now please try:
>
> http://www.cs.ucla.edu/~eggert/coreutils-8.23.211-b1d1a.tar.xz
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 17:54:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/06/15 17:02, Michael Felt wrote:
> Attribute "constructor" is not supported
Does the attached patch help?
thanks,
Pádraig.
[avoid-stdbuf-aix.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 19:28:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/05/2015 11:53 AM, Pádraig Brady wrote:
> On 05/06/15 17:02, Michael Felt wrote:
>> > Attribute "constructor" is not supported
>
> Does the attached patch help?
>
> +++ b/configure.ac
> @@ -455,7 +455,11 @@ if test $gl_cv_list_mounted_fs = yes && test $gl_cv_fs_space = yes; then
> fi
>
> AC_MSG_CHECKING([whether this is system supports stdbuf])
> -AC_COMPILE_IFELSE(
> +ac_save_CFLAGS="$CFLAGS"
> +# Build with -Werror to detect warnings about
> +# about ignored "constructor" arguments.
> +CFLAGS="$CFLAGS -Werror"
-Werror works for gcc and some other compilers like clang, but is not
universal to all compilers. Are you sure that it is the right flag to
be adding for the duration of this test?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Fri, 05 Jun 2015 21:35:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/06/15 20:27, Eric Blake wrote:
> On 06/05/2015 11:53 AM, Pádraig Brady wrote:
>> On 05/06/15 17:02, Michael Felt wrote:
>>>> Attribute "constructor" is not supported
>>
>> Does the attached patch help?
>>
>
>> +++ b/configure.ac
>> @@ -455,7 +455,11 @@ if test $gl_cv_list_mounted_fs = yes && test $gl_cv_fs_space = yes; then
>> fi
>>
>> AC_MSG_CHECKING([whether this is system supports stdbuf])
>> -AC_COMPILE_IFELSE(
>> +ac_save_CFLAGS="$CFLAGS"
>> +# Build with -Werror to detect warnings about
>> +# about ignored "constructor" arguments.
>> +CFLAGS="$CFLAGS -Werror"
>
> -Werror works for gcc and some other compilers like clang, but is not
> universal to all compilers. Are you sure that it is the right flag to
> be adding for the duration of this test?
Yes good point.
Also it's best only worry about warnings when cross compiling,
as otherwise we're using a direct runtime check.
Updated patch is attached.
thanks,
Pádraig.
[avoid-stdbuf-aix.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 02:55:03 GMT)
Full text and
rfc822 format available.
Message #115 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I assume the error is mine, but I do not understand what.
After automake and autoconf (just to be sure) make wants to call "missing",
but that does not succeed.
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/build-aux/missing
aclocal-1.15 -I m4
aclocal-1.15: error: echo failed with exit status: 1
make: *** [aclocal.m4] Error 1
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]1d1a/build-aux/missing
aclocal-1.15 -I m4 <
aclocal-1.15: error: echo failed with exit status: 1
ran by hand - as /bin/sh -x ...
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]/bin/sh -x
/data/prj/gnu/coreutils/coreutils-8.23.21>
+ scriptversion=2013-10-28.13
+ test 3 -eq 0
+ aclocal-1.15 -I m4
aclocal-1.15: error: echo failed with exit status: 1
+ st=1
+ test 1 -eq 0
+ test 1 -eq 63
+ test 1 -eq 127
+ exit 1
On Fri, Jun 5, 2015 at 11:34 PM, Pádraig Brady <P <at> draigbrady.com> wrote:
> On 05/06/15 20:27, Eric Blake wrote:
> > On 06/05/2015 11:53 AM, Pádraig Brady wrote:
> >> On 05/06/15 17:02, Michael Felt wrote:
> >>>> Attribute "constructor" is not supported
> >>
> >> Does the attached patch help?
> >>
> >
> >> +++ b/configure.ac
> >> @@ -455,7 +455,11 @@ if test $gl_cv_list_mounted_fs = yes && test
> $gl_cv_fs_space = yes; then
> >> fi
> >>
> >> AC_MSG_CHECKING([whether this is system supports stdbuf])
> >> -AC_COMPILE_IFELSE(
> >> +ac_save_CFLAGS="$CFLAGS"
> >> +# Build with -Werror to detect warnings about
> >> +# about ignored "constructor" arguments.
> >> +CFLAGS="$CFLAGS -Werror"
> >
> > -Werror works for gcc and some other compilers like clang, but is not
> > universal to all compilers. Are you sure that it is the right flag to
> > be adding for the duration of this test?
>
> Yes good point.
>
> Also it's best only worry about warnings when cross compiling,
> as otherwise we're using a direct runtime check.
> Updated patch is attached.
>
> thanks,
> Pádraig.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 03:50:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 20733 <at> debbugs.gnu.org (full text, mbox):
On 06/06/15 03:54, Michael Felt wrote:
> I assume the error is mine, but I do not understand what.
>
> After automake and autoconf (just to be sure) make wants to call "missing", but that does not succeed.
>
>
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/build-aux/missing aclocal-1.15 -I m4
> aclocal-1.15: error: echo failed with exit status: 1
> make: *** [aclocal.m4] Error 1
> root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]1d1a/build-aux/missing aclocal-1.15 -I m4 <
> aclocal-1.15: error: echo failed with exit status: 1
That suggests a problem with configure.ac though I don't see what,
nor do reproduce the issue here. Were both hunks of the second patch applied?
Note both patches I supplied are against the original configure.ac from the tarball.
I.E. please use the orig configure.ac from the tarball and apply only the second patch.
thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 07:52:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I installed the attached further patches to gnulib and to coreutils,
respectively. Could you please try:
http://www.cs.ucla.edu/~eggert/coreutils-8.23.212-d8a5.tar.xz
[0001-acl-permissions-more-porting-to-AIX.patch (text/x-patch, attachment)]
[0001-build-update-gnulib-submodule-to-latest.patch (text/x-patch, attachment)]
[0002-build-port-to-AIX.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 08:36:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I had only applied the last patch, not both - so I shall backup to the
coreutils-8.23.211-b1d1a.tar.xz
and apply only the second patch. This is what I thought had been done - but
at least then I will not be working from one where configure has already
been run.
michael <at> x071:[/data/prj/gnu/coreutils]xz -dc
coreutils-8.23.211-b1d1a.tar.xz | tar xf -
michael <at> x071:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]cat
../avoid* | patch -p1
(Stripping trailing CRs from patch.)
patching file configure.ac
Same as yesterday - so looks like only one hunk had been applied.
*** time passing ***
Oh yes, forgot something... - would be 'nice' if this test happened in the
beginning...
configure: error: you should not run configure as root (set
FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)
See `config.log' for more details
*** NEW SUMMARY - short story: there is a perl and a buffer dependency
that make AIX 5.3 TL7 a poor autoconf/automake platform ***
michael <at> x071:[/data/prj/gnu/coreutils]xz -dc
coreutils-8.23.211-b1d1a.tar.xz | tar xf -
michael <at> x071:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]cat
../avoid* | patch -p1
(Stripping trailing CRs from patch.)
patching file configure.ac
# modified 'missing'
# Run the given program, remember its exit status.
/bin/sh -x "$@"; st=$?
Did not say much new, so adding -x to start of aclocal...
Ah - aclocal is perl - maybe they need something different from perl (I
have reinstalled this system without my own perl update!)
So I updated perl to perl-5.10.1 and now I get, sadly,
....
truncated
C_MESSAGES:$f::$n' --trace='AM_XGETTEXT_OPTION:$f::$n'
--trace='gl_LANGINFO_H:$f::$n' --trace='gl_PREREQ_FTELLO:$f::$n'
--trace='gl_ASSERT_NO_GNULIB_POSIXCHECK:$f::$n'
--trace='gl_HEADER_ARPA_INET:$f::$n' --trace='gl_ISNANF_WORKS:$f::$n'
--trace='gl_FUNC_STRTOUMAX:$f::$n' --trace='gl_HUMAN:$f::$n'
--trace='gl_FILE_SYSTEM_USAGE:$f::$n' --trace='gl_PRINTF_INFINITE:$f::$n'
--trace='gl_ABSOLUTE_HEADER_ONE:$f::$n'
--trace='gl_PREREQ_INET_NTOP:$f::$n' --trace='gl_STDARG_H:$f::$n'
configure.ac |: Arg list too long
Short message: aclocal does not check perl version when it seems it needs a
new version.
At least perl-5.8.2 does not work, while perl-5.10.1 ends in arg to long -
on AIX 5.3
So, I switched to a different server - with AIX 6.1, and a self-packaged
perl (5.14.1) - the aclocal completes.
So, as far as aclocal is concerned I will call it an AIX 5.3 bug - cannot
be fixed, that is holding up the aclocal, etc..
After running make clean, I restarted the make on the AIX 5.3 system.
Looking much better - and now I am 'stuck' because I do not understand what
is different about this man page, that it fails.
GEN man/tee.1
GEN man/test.1
help2man: can't get `--help' info from man/test.td/[
Try `--no-discard-stderr' if option outputs to stderr
make: 1254-004 The error code from the last command is 127.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
Making all in po
Target "all" is up to date.
Making all in .
name=`echo man/test.1 | sed 's|.*/||; s|\.1$||'` || exit 1;
case $name in install)
prog='ginstall'; argv=$name;; test) prog='[';
argv='[';; *) prog=$name;
argv=$prog;;
esac; rm -f
man/test.1 man/test.1-t
&& t=man/test.td &&
rm -rf $t &&
build-aux/install-sh -c -d
$t && (cd $t && ln -s
'/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/src/'$prog
$argv) && perl --
./man/help2man --source='GNU
coreutils 8.23.211-b1d1a'
--include=./man/$name.x
--output=$t/$name.1
--info-page='\(aq(coreutils) '$name' invocation\(aq'
$t/$argv && sed -e 's|man/test\.td/||g' -e '/For
complete documentation/d' $t/$name.1 > man/test.1-t && rm
-rf $t && chmod a-w
man/test.1-t && mv
man/test.1-t man/test.1
help2man: can't get `--help' info from man/test.td/[
Try `--no-discard-stderr' if option outputs to stderr
make: 1254-004 The error code from the last command is 127.
Stop.
make: 1254-004 The error code from the last command is 1.
Simple solution, rather hack - what ./configure option stops the man pages
from being generated? Now I am back at the same problem I had with 8.21 -
when I revisited packaging it.
I know I do not have 'gettext, or makeinfo installed' - maybe that is
enough.
FYI: I am going through these builds on an extremely 'barebones' install of
AIX - just the base install, no openssl or other stuff - to really find
dependancies.
AND!! I would like to thank you now for your assistence and patience as I
go through this process - 'coreutils' is the first I am repackaging as I
research what needs to be done to be TLS1.2 safe.
p.s. On the 'tool' loaded system, the make finishes...
make[2]: Entering directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a'
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/build-aux/missing
autoheader)
+ eval case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S
"$0" "$@";; esac
+ exec /usr/bin/perl -S autoheader
rm -f lib/stamp-h1
touch lib/config.hin
cd . && /bin/sh ./config.status lib/config.h
config.status: creating lib/config.h
config.status: lib/config.h is unchanged
CC src/lbracket.o
CCLD src/[
GEN man/test.1
GEN man/timeout.1
GEN man/touch.1
GEN man/tr.1
GEN man/true.1
GEN man/truncate.1
GEN man/tsort.1
GEN man/tty.1
GEN man/uname.1
GEN man/unexpand.1
GEN man/uniq.1
GEN man/unlink.1
GEN man/vdir.1
GEN man/wc.1
GEN man/whoami.1
GEN man/yes.1
GEN lib/charset.alias
GEN lib/ref-add.sed
GEN lib/ref-del.sed
make[2]: Leaving directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a'
Making all in gnulib-tests
make[2]: Entering directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/gnulib-tests'
GEN arg-nonnull.h
GEN c++defs.h
GEN unused-parameter.h
GEN warn-on-use.h
make all-recursive
make[3]: Entering directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/gnulib-tests'
Making all in .
make[4]: Entering directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/gnulib-tests'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/gnulib-tests'
make[3]: Leaving directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/gnulib-tests'
make[2]: Leaving directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/gnulib-tests'
make[1]: Leaving directory
`/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a'
root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]
So, the good news is, the patch works - and the last bit works too. Just
have to figure out what is different between the systems.
If you have ideas - please reply.
And again, my heartfelt thanks!
On Sat, Jun 6, 2015 at 5:48 AM, Pádraig Brady <P <at> draigbrady.com> wrote:
> On 06/06/15 03:54, Michael Felt wrote:
> > I assume the error is mine, but I do not understand what.
> >
> > After automake and autoconf (just to be sure) make wants to call
> "missing", but that does not succeed.
> >
> >
> > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
> /data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a/build-aux/missing
> aclocal-1.15 -I m4
> > aclocal-1.15: error: echo failed with exit status: 1
> > make: *** [aclocal.m4] Error 1
> > root <at> x064:[/data/prj/gnu/coreutils/coreutils-8.23.211-b1d1a]1d1a/build-aux/missing
> aclocal-1.15 -I m4 <
> > aclocal-1.15: error: echo failed with exit status: 1
>
> That suggests a problem with configure.ac though I don't see what,
> nor do reproduce the issue here. Were both hunks of the second patch
> applied?
> Note both patches I supplied are against the original configure.ac from
> the tarball.
> I.E. please use the orig configure.ac from the tarball and apply only the
> second patch.
>
> thanks,
> Pádraig.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 13:34:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 20733 <at> debbugs.gnu.org (full text, mbox):
On 06/06/15 08:51, Paul Eggert wrote:
> I installed the attached further patches to gnulib and to coreutils,
> respectively. Could you please try:
>
> http://www.cs.ucla.edu/~eggert/coreutils-8.23.212-d8a5.tar.xz
Thanks for doing all that!
It all looks good and sensible.
I made a couple of tweaks at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3150ec9
thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 16:33:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I downloaded, unpacked, ran configure and then "make -i". The only thing
notable is still the problem with the man page for 'test' aka '['
(right_bracket)
GEN man/test.1
help2man: can't get `--help' info from man/test.td/[
Try `--no-discard-stderr' if option outputs to stderr
make: 1254-004 The error code from the last command is 127.
make: 1254-005 Ignored error code 127 from last command.
I will try again with gmake - that may be the 'telling' difference between
the two systems.
On Sat, Jun 6, 2015 at 9:51 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> I installed the attached further patches to gnulib and to coreutils,
> respectively. Could you please try:
>
> http://www.cs.ucla.edu/~eggert/coreutils-8.23.212-d8a5.tar.xz
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 16:46:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
So, if it is intentional - then it is working as designed (you may want to
add a check for gmake then), otherwise - the way "non-gnu make(s)" handle
the '[' character "break things".
Now, running /opt/bin/make (to be sure!) at the pain point I see:
GEN man/sum.1
GEN man/sync.1
GEN man/tac.1
GEN man/tail.1
GEN man/tee.1
GEN man/test.1
GEN man/timeout.1
GEN man/touch.1
GEN man/tr.1
GEN man/true.1
(Note: GEN man/test.1 is suppossed to be visible as white text with a blue
background - just in case)
I, personally, am happy enough that I can run the configure command without
gmake being installed (as that also requires gnu.gettext to be loaded and I
am trying to avoid an unneeded dependency on gettext. I want to be
specifically aware of the dependencies. And as often as it requires I will
just build in phases.)
Many thanks again.
On Sat, Jun 6, 2015 at 6:32 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
> I downloaded, unpacked, ran configure and then "make -i". The only thing
> notable is still the problem with the man page for 'test' aka '['
> (right_bracket)
>
> GEN man/test.1
> help2man: can't get `--help' info from man/test.td/[ <http://test.td/%5B>
> Try `--no-discard-stderr' if option outputs to stderr
> make: 1254-004 The error code from the last command is 127.
> make: 1254-005 Ignored error code 127 from last command.
>
> I will try again with gmake - that may be the 'telling' difference
> between the two systems.
>
>
> On Sat, Jun 6, 2015 at 9:51 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
>> I installed the attached further patches to gnulib and to coreutils,
>> respectively. Could you please try:
>>
>> http://www.cs.ucla.edu/~eggert/coreutils-8.23.212-d8a5.tar.xz
>>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 18:29:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Michael Felt wrote:
> I downloaded, unpacked, ran configure and then "make -i". The only thing
> notable is still the problem with the man page for 'test' aka '['
> (right_bracket)
>
> GEN man/test.1
Yes, somehow AIX make is losing the dependency of man/test.1 on src/[ perhaps
because it treats [ specially (but why would it?). Anyway, one workaround is to
use gmake, another is to do 'make src/[' by hand first, before doing 'make'. At
some point someone with AIX access and time to burn might look into working
around the AIX make glitch.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 21:30:05 GMT)
Full text and
rfc822 format available.
Message #139 received at 20733 <at> debbugs.gnu.org (full text, mbox):
On 06/06/15 17:32, Michael Felt wrote:
> I downloaded, unpacked, ran configure and then "make -i". The only thing notable is still the problem with the man page for 'test' aka '[' (right_bracket)
>
> GEN man/test.1
> help2man: can't get `--help' info from man/test.td/[ <http://test.td/[>
> Try `--no-discard-stderr' if option outputs to stderr
> make: 1254-004 The error code from the last command is 127.
> make: 1254-005 Ignored error code 127 from last command.
Does something hacky like this workaround the issue with your make?
diff --git a/man/local.mk b/man/local.mk
index 45bda93..bf6a662 100644
--- a/man/local.mk
+++ b/man/local.mk
@@ -58,7 +58,8 @@ else
# Most prog.1 man pages depend on src/prog. List the exceptions:
man/arch.1: src/uname$(EXEEXT)
man/install.1: src/ginstall$(EXEEXT)
-man/test.1: src/[$(EXEEXT)
+LBRACKET = [
+man/test.1: src/$(LBRACKET)$(EXEEXT)
man/base64.1: src/base64$(EXEEXT)
man/basename.1: src/basename$(EXEEXT)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sat, 06 Jun 2015 22:11:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 20733 <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote:
> -man/test.1: src/[$(EXEEXT)
> +LBRACKET = [
> +man/test.1: src/$(LBRACKET)$(EXEEXT)
I'm afraid that doesn't work, no. For example, with this Makefile:
LBRACKET = [
a: b/$(LBRACKET)
echo a b/$(LBRACKET)
On AIX a plain 'make' will output:
echo a b/[
a b/[
whereas 'make LBRACKET=x' will fail with:
make: 1254-002 Cannot find a rule to create target b/x from dependencies.
Stop.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#20733; Package
coreutils.
(Sun, 07 Jun 2015 00:13:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 20733 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I can certainly install a test partition and give someone access to work
through this. Just contact me privately and we can get it in motion. Takes
a bit less than 10 minutes to do a fresh install (compiler is in the backup
image being restored).
On Sun, Jun 7, 2015 at 12:10 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Pádraig Brady wrote:
>
>> -man/test.1: src/[$(EXEEXT)
>> +LBRACKET = [
>> +man/test.1: src/$(LBRACKET)$(EXEEXT)
>>
>
> I'm afraid that doesn't work, no. For example, with this Makefile:
>
> LBRACKET = [
> a: b/$(LBRACKET)
> echo a b/$(LBRACKET)
>
> On AIX a plain 'make' will output:
>
> echo a b/[
> a b/[
>
> whereas 'make LBRACKET=x' will fail with:
>
> make: 1254-002 Cannot find a rule to create target b/x from dependencies.
> Stop.
>
>
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 05 Jul 2015 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 301 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.