bug#10898: test-suite output of automake-1.11.3 - it requested I send it to you!

[Stefano Lattarini]

Hi Lou, thanks for the report.

On 02/27/2012 05:53 PM, Lou Picciano wrote:
> Building - and testing - significantly more completely now...
> 
> Build is on OpenIndiana 151a2 (illumos/née OpenSolaris) - and, yes; will 
> certainly keep an eye out for the upcoming ßeta.
> 
> Regards, Lou Picciano
> 
> =====================================
> 5 of 787 tests failed
> (151 tests were not run)
> See tests/test-suite.log
> Please report to address@hidden
> =====================================
> 

> FAIL: ansi2knr-deprecation.test (exit: 1)
> =========================================
>
> [SNIP]
>
OK, this is almost surely a spurious failure due to a testsuite weakness
(we were forgetting to clobber a possibly out-of-date autom4te cache);
absolutely nothing to worry about ...  And moreover, the 'ansi2knr' support
is strongly deprecated in automake 1.11.2 already, and will be removed
altogether in automake 1.12.  You can safely ignore this error.

> FAIL: automake.test (exit: 1)
> =============================
>
> [SNIP]
>
> + test 1 = 1
> + grep 'input file.*--voo' stderr
> automake: no Automake input file found for `--voo'
> + AUTOMAKE_fails ''
> + AUTOMAKE_run 1
> + expected_exitcode=1
> + shift
> + exitcode=0
> + automake-1.11 --foreign -Werror -Wall
> + 1> stdout 2> stderr
> + exitcode=1
> + cat stderr
> + 1>& 2
> configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
> configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
> configure.in: that aclocal.m4 is present in the top-level directory,
> configure.in: and that aclocal.m4 was recently regenerated (using aclocal).
> automake: no `Makefile.am' found for any configure output
> + cat stdout
> + test 1 = 1
> + grep 'empty argument' stderr
> + exit_status=1
>
Ah, likely the famous ksh bug with "$@" and empty arguments:

 <http://lists.gnu.org/archive/html/automake-patches/2009-12/msg00037.html>

Can you verify that your shell suffers of the problem described there?  If
yes, a patch to fix this issue should be trivial.

> FAIL: instfail.test (exit: 1)
> =============================
>
> [SNIP]
>
> WARNING: Warnings can be ignored. :-)
> if test "emacs" != no; then \
>   set x; \
>   list='lisp1.el lisp2.el lisp3.el lispn1.el lispn2.el lispn3.el'; for p in 
> $list; do \
>     if test -f "$p"; then d=; else d="./"; fi; \
>     set x "$@" "$d$p"; shift; \
>   done; \
>   shift; \
>   EMACS="emacs" /bin/sh ./elisp-comp "$@" || exit 1; \
> else : ; fi
> /usr/bin/emacs: no emacs binaries available. Install software package
> SUNWgnu-emacs-gtk, SUNWgnu-emacs-x, or SUNWgnu-emacs-nox
> *** Error code 1
> make: Fatal error: Command failed for target `elc-stamp'
> + exit_status=1
> instfail: exit 1
>
Spurious error due to a broken emacs installation, not automake's fault.

> FAIL: instspc.test (exit: 1)
> ============================
>
> [SNIP]
>
> + mkdir sub1 ./a:
> + cd a:
> .../instspc.test[137]: cd: a:: [No such file or directory]
> + exit_status=1
>
I remember seeing a similar problem when testing with ksh on Solaris; this is a
spurious failure due to a ksh bug, nothing to worry about.  Moreover, the
instspc.test has been extensively rewritten in master, and made more resilient
to this kind of shell bugs (if you think this failure is weird, you should see
the one on MSYS ;-).  In case you re-encounter this failure with automake from
master, feel free to open a new report.

> FAIL: subpkg4.test (exit: 1)
> ============================
>
> + make distdir
> ...
> find "../subpkg4-1.0/subpkg" -type d ! -perm -755 \
>       -exec chmod u+rwx,go+rx {} \; -o \
>  ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
>  ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
> ...
>
> find: bad option -links
> find: [-E] [-H | -L] path-list predicate-list
>
Oops, your find (1) doesn't support the '-links' option, which is mandated by
POSIX: <http://pubs.opengroup.org/onlinepubs/009604599/utilities/find.html>.
Also, both Solaris 10 /usr/xpg4/bin/find and /usr/bin/find support it (I've
just checked).
Can you try to re-run this test with a more capable 'find' program early
in path, like GNU find?  Does the test fails in this case as well?

Thanks,
  Stefano