bug#20733: coreutils build problem

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 wrote

bug#20733: coreutils build problem

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/[

bug#20733: coreutils build problem

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/[

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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 twe

bug#20733: coreutils build problem

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@x071:[/data/prj/gnu/coreutil

bug#20733: coreutils build problem

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 >From 4e02fe2fa7eaf841e8f84bf3a370ba4475ebee3c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 5 Jun 2015 11:47:37 -0700

bug#20733: coreutils build problem

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/coreutil

bug#20733: coreutils build problem

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 acl

bug#20733: coreutils build problem

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 &&

bug#20733: coreutils build problem

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 >

bug#20733: coreutils build problem

On 05/06/15 17:02, Michael Felt wrote: > Attribute "constructor" is not supported Does the attached patch help? thanks, Pádraig. >From 2356b3663f8d08b7d3d1e4496f22dcea3c5b76b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Fri, 5 Jun 2015 18:49:48 +0100 Subject: [PATCH] b

bug#20733: coreutils build problem

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 o

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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 wrote: > On 06/05/2015 08:09 AM, Michael Felt wrote: > > root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1 > > rm -f src/coreutils.h > > for prog in ; do

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

On 06/05/2015 08:09 AM, Michael Felt wrote: > root@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 Makef

bug#20733: coreutils build problem

Michael Felt wrote: root@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 n

bug#20733: coreutils build problem

root@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

bug#20733: coreutils build problem

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'?

bug#20733: coreutils build problem

This is reassuring. Thank you for the reply. On Fri, Jun 5, 2015 at 3:05 PM, Eric Blake 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 intro

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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 i

bug#20733: coreutils build problem

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 Novembe

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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@x071:[/data/prj/gnu/coreutils]xz -dc *23*xz | tar xf - michael@x071:[/data/prj/gnu/coreutils

bug#20733: coreutils build problem

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, unpa

bug#20733: coreutils build problem

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 wrote: > I think I still have automake 1

bug#20733: coreutils build problem

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@

bug#20733: coreutils build problem

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

bug#20733: coreutils build problem

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 some

bug#20733: coreutils build problem

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 ski

bug#20733: coreutils build problem

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 pr

bug#20733: coreutils build problem

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,

bug#20733: coreutils build problem

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 th

bug#20733: coreutils build problem

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? > >

bug#20733: coreutils build problem

On 06/04/2015 01:35 PM, Andreas Schwab wrote: > Paul Eggert 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)")

bug#20733: coreutils build problem

Paul Eggert 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

bug#20733: coreutils build problem

[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_

bug#20733: coreutils build problem

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