bug#20733: coreutils build problem

[Michael Felt]

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 <address@hidden> 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 <address@hidden> 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.

address@hidden:[/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.)
address@hidden:[/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,

address@hidden:[/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 <address@hidden> 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)

address@hidden:[/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 <address@hidden> 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 <address@hidden> 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