Re: 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
>>>>>
>>>>>
>>>>
>>>
>>
>