[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#20733: coreutils build problem
From: |
Michael Felt |
Subject: |
Re: bug#20733: coreutils build problem |
Date: |
Fri, 5 Jun 2015 13:13:21 +0200 |
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
>>>
>>>
>>
>
- Re: bug#20733: coreutils build problem, Eric Blake, 2015/06/04
- Re: bug#20733: coreutils build problem, Nick Bowler, 2015/06/04
- Re: bug#20733: coreutils build problem, Paul Eggert, 2015/06/04
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Eric Blake, 2015/06/05
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Paul Eggert, 2015/06/05
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Paul Eggert, 2015/06/05
- Re: bug#20733: coreutils build problem, Michael Felt, 2015/06/05
- Re: bug#20733: coreutils build problem, Eric Blake, 2015/06/05