bug#13314: GNU Automake 1.12.6 Testsuite FAIL: 2 on Solaris 10

[Stefano Lattarini]

Hi Dennis, thanks for the report.

On 12/31/2012 09:19 AM, Dennis Clarke wrote:
> 
> Happy New Year  ;-)
> 
> 
> Testsuite summary for GNU Automake 1.12.6
> 
> # TOTAL: 2879
> # PASS:  2773
> # SKIP:  65
> # XFAIL: 39
> # FAIL:  2
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to bug-automake@gnu.org
> 
> 
Yay, finally a decent testsuite behaviour :-)

So, let's look in more detail at those two failures ...

> FAIL: t/cxx-lt-demo
> ===
>
> [SNIP]
>
> + /usr/local/bin/gmake -e
> Making all in lib
> gmake[1]: Entering directory 
> `/usr/local/build/automake-1.12.6_SunOS5.10_sparcv9/t/cxx-lt-demo.dir/lib'
> echo '#include ' >libfoo.h++-t
> grep "target *(" "./libfoo.c++" >>libfoo.h++-t
> echo ';' >>libfoo.h++-t
> chmod a-w libfoo.h++-t && mv -f libfoo.h++-t libfoo.h++
> /usr/local/bin/gmake  all-am
> gmake[2]: Entering directory 
> `/usr/local/build/automake-1.12.6_SunOS5.10_sparcv9/t/cxx-lt-demo.dir/lib'
> /usr/local/bin/libtool --tag=CXX   --mode=compile /usr/local/gcc4/bin/g++ \
>   -DPACKAGE_NAME=\"GNU\ C++/Libtool\ Demo\" 
> -DPACKAGE_TARNAME=\"c---libtool-demo\" \
>   -DPACKAGE_VERSION=\"0.73\" -DPACKAGE_STRING=\"GNU\ C++/Libtool\ Demo\ 
> 0.73\" \
>   -DPACKAGE_BUGREPORT=\"bug-automake@gnu.org\" \
>   -DPACKAGE_URL=\"http://www.gnu.org/software/c---libtool-demo/\"; \
>   -DPACKAGE=\"c---libtool-demo\" -DVERSION=\"0.73\" -DSTDC_HEADERS=1 \
>   -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
> -DHAVE_STRING_H=1 \
>   -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 \
>   -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" \
>   -I.  -I/usr/local/include:/usr/local/gcc4/include  -mno-app-regs -mcpu=v9 \
>   -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
> -D_TS_ERRNO \
>   -MT libfoo.lo -MD -MP -MF .deps/libfoo.Tpo -c -o libfoo.lo libfoo.c++
> libtool: compile:  /usr/local/gcc4/bin/g++ "-DPACKAGE_NAME=\"GNU C++/Libtool 
> Demo\"" ...\
>   -MT libfoo.lo -MD -MP -MF .deps/libfoo.Tpo -c libfoo.c++ -KPIC -DPIC -o 
> .libs/libfoo.o
> g++: error: unrecognized command line option '-KPIC'
> gmake[2]: *** [libfoo.lo] Error 1
> gmake[2]: Leaving directory 
> `/usr/local/build/automake-1.12.6_SunOS5.10_sparcv9/t/cxx-lt-demo.dir/lib'
>
This failure seems actually due to a Libtool bug rather than an
Automake one, since Autoamke does not fiddle with these compiler
flags itself.  So we can safely ignore it here (if you feel like
writing a smaller reproducer and reporting the issue to the
Libtool list, you're of course very welcome to do so ;-)

> FAIL: t/silent-many-generic
> ===
> + /usr/local/bin/gmake
> baz3.f:
>   foo3:
> ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
> ld: fatal: file processing errors. No output written to baz
> collect2: error: ld returned 1 exit status
> gmake[3]: *** [baz] Error 1
> gmake[2]: *** [all] Error 2
> gmake[1]: *** [all-recursive] Error 1
> gmake: *** [all] Error 2
>
I'm a little lost here.  Perhaps a mismatch between the object files
generated by the GNU C/C++ compilers and the non-GNU Fortran ones?
What happens if you re-run this test forcing $FC and $F77 to point
to GNU compilers?  And what if you re-run it forcing $CC and $CXX
to point to non-GNU compilers?

> gcc_spec_node002 $ uname -a 
> SunOS node002 5.10 Generic_147440-23 sun4v sparc SUNW,T5240
> gcc_spec_node002 $ 
> gcc_spec_node002 $ cat /etc/release 
>Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
>   Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
> Assembled 23 August 2011
> 
> 
> I'm sure everything is in the log file attached 
> 
> Dennis Clarke 
> dcla...@blastwave.org
> 
> ps: the testsuite is one obscene long process .. time -p says : 
> 
> real 28915.31
> user 15317.85
> sys 5091.92
> 
>eeek.
> 
In you have a decent machine, you should try running make in concurrent
mode to speed-up the process; as in, say:

$ make check -j16

Regards,
  Stefano

P.S. Automake 1.13 is out ;-)

bug#12962: close report

[Stefano Lattarini]

Reference: 

This report as been superseded by this new one:


I'm thus closing the old report.

Regards,
 Stefano

bug#13314: GNU Automake 1.12.6 Testsuite FAIL: 2 on Solaris 10

[Stefano Lattarini]

On 01/01/2013 12:37 AM, Dennis Clarke wrote:
> 
>> Yay, finally a decent testsuite behaviour :-)
> 
> I forgot to look and see if a newer release was available ..
> therefore I present this one :
> 
> 
> Testsuite summary for GNU Automake 1.13
> 
> # TOTAL: 2874
> # PASS:  2762
> # SKIP:  72
> # XFAIL: 38
> # FAIL:  2
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to bug-automake@gnu.org
> 
>
Thanks for having taken the time to re-run the testsuite for the umpteenth
time.

> 
> I attach the log as per usual and maybe we have to update that bug again ?  
> 
Nah, it's fine; they are the same spurious failures as before, and my
previous observations and questions apply.

Thanks,
  Stefano

bug#13317: automake fails make check

[Stefano Lattarini]

On 12/31/2012 09:21 AM, Ronald Copley wrote:
> Log attached
> 
Thanks.  I haven't looked at it in detail yet, but a cursory look has
already helped me to find and fix some latent testsuite issues (patches
for them are attached).  I hope I'll be able to look in more depth at
your report in the next days.

Best regards, and happy new year,
  Stefano
>From f2443786a7dec55f498c06b8b207751aa06368cf Mon Sep 17 00:00:00 2001
Message-Id: 
From: Stefano Lattarini 
Date: Tue, 1 Jan 2013 00:51:37 +0100
Subject: [PATCH 1/2] tests: fix bug in pkg-config-macros.sh, could cause
 spurious SKIPs

Issue spotted perusing the testsuite logs reported in bug#13317.

* t/pkg-config-macros.sh: Don't use (uninitialized) '$dir' where '$d'
should have been used instead.  Set IFS to ':' before looping on the
$PATH expansion.  Fix typo: 'alocal' instead of 'aclocal'.  These
issues were causing the location in PATH of the 'pkg-config' program
not to be found even when the program was present.
* THANKS: Update.

Signed-off-by: Stefano Lattarini 
---
 THANKS | 1 +
 t/pkg-config-macros.sh | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/THANKS b/THANKS
index 1ff7c08..5fa307d 100644
--- a/THANKS
+++ b/THANKS
@@ -337,6 +337,7 @@ Robert Collins  robert.coll...@itdomain.com.au
 Robert Swafford robert.swaff...@l-3com.com
 Roberto Bagnara bagn...@cs.unipr.it
 Roman Fietzeroman.fie...@telemotive.de
+Ronald Copley   ronald.cop...@gmail.com
 Ronald Landheer ron...@landheer.com
 Roumen Petrov   bugtr...@roumenpetrov.info
 Russ Allberyr...@stanford.edu
diff --git a/t/pkg-config-macros.sh b/t/pkg-config-macros.sh
index ec8b381..5069c08 100755
--- a/t/pkg-config-macros.sh
+++ b/t/pkg-config-macros.sh
@@ -48,9 +48,10 @@ XT_ACLOCAL_PATH=/usr/local/share/aclocal:/usr/share/aclocal
 
 # Find the location of the pkg-config executable.
 oIFS=$IFS dir=
+IFS=:
 for d in $PATH; do
   IFS=$oIFS
-  if test -f $dir/pkg-config || test -f $dir/pkg-config.exe; then
+  if test -f $d/pkg-config || test -f $d/pkg-config.exe; then
 dir=$d
 break
   fi
@@ -61,7 +62,7 @@ IFS=$oIFS
 # where the corresponding pkg.m4 might be installed.
 if test -n "$dir"; then
   # Only support standard installation layouts.
-  XT_ACLOCAL_PATH=${dir%/bin}/share/alocal:$XT_ACLOCAL_PATH
+  XT_ACLOCAL_PATH=${dir%/bin}/share/aclocal:$XT_ACLOCAL_PATH
 fi
 
 XT_ACLOCAL_PATH=$XT_ACLOCAL_PATH${ACLOCAL_PATH+":$ACLOCAL_PATH"}
-- 
1.8.1.rc3.27.g3b73c7d

>From f87ce5b01869361bb9f1035ae9f45bbf5e76b8bc Mon Sep 17 00:00:00 2001
Message-Id: 
In-Reply-To: 
References: 
From: Stefano Lattarini 
Date: Tue, 1 Jan 2013 01:20:49 +0100
Subject: [PATCH 2/2] tests: don't always look for a C++ compiler named 'RCC'

On MacOS X (10.8), since the file system is case-insensitive, RCC
can point to the "Resource Compiler" of the Qt4 Toolkit:



That mismatch causes our configure script to erroneously think that
no working C++ compiler is present, and that is thus necessary to
skip all the test cases requiring such a compiler.

So only look for a compiler named 'RCC' if the file system is
case-sensible.

Issue spotted analyzing the testsuite logs reported in bug#13317.

* configure.ac: Adjust.

Signed-off-by: Stefano Lattarini 
---
 configure.ac | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index a62743f..6822639 100644
--- a/configure.ac
+++ b/configure.ac
@@ -470,12 +470,14 @@ AS_IF([test x"$GCC" = x"yes"], [am_CC_is_GNU=yes], [am_CC_is_GNU=no])
 # On case-insensitive file systems (seen e.g. on Cygwin and Mac OS X)
 # we must avoid looking for 'CC', because that would be the same as
 # 'cc', and could cause $CXX to point to the C compiler, instead of
-# to a C++ compiler as expected.  See automake bugs #11893 and #10766.
+# to a C++ compiler as expected (see automake bugs #11893 and #10766).
+# Similarly, we must avoid looking for 'RCC', as that can point to the
+# Qt4 "Resource Compiler": 
 if test -f /bIn/rMdIr || test -f /uSr/bIn/rMdIr; then
   # Case-insensitive file system, don't look for CC.
-  am_CC=
+  am_CC= am_RCC=
 else
-  am_CC=CC
+  am_CC=CC am_RCC=RCC
 fi
 
 # The list of C++ compilers here has been copied, pasted and edited
@@ -483,7 +485,7 @@ fi
 # Keep it in sync, or better again, find out a way to avoid this code
 # duplication.
 _AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl
-  [aCC $am_CC FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])],
+  [aCC $am_CC FCC KCC $am_RCC xlC_r xlC c++ cxx cc++ gpp g++])],
   [CXX=false; _AM_SKIP_COMP_TESTS([C++])])
 
 AS_IF([test x"$GXX" = x"yes"], [am_CXX_is_GNU=yes], [am_CXX_is_GNU=no])
-- 
1.8.1.rc3.27.g3b73c7d

bug#13314: GNU Automake 1.12.6 Testsuite FAIL: 2 on Solaris 10

[Dennis Clarke]

 
> Nah, it's fine; they are the same spurious failures as before, and my
> previous observations and questions apply.

awesome .. I am at least on the correct rev now. 

dc

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

[Stefano Lattarini]

Severity: wishlist

Hi Karl.

I'm adding bug-automake in CC, so that this discussion will remain visible
and archived in a singe place, and we won't forget about the issue.

On 01/01/2013 01:38 AM, Karl Berry wrote:
> Stefano and all,
> 
> It would be nice to able to list directories in EXTRA_DIST. 
>
That is already possible:


> It is painful and unnecessary overhead to list every file in a contrib
> directory individually just to avoid including VC files.  (As explained at
> http://www.gnu.org/software/automake/manual/automake.html#Basics-of-Distribution.)
> 
> I don't propose any major surgery to make it work in every conceivable
> circumstance.  All that is really necessary is to provide a way to pass
> --exclude-vcs to tar.  It would only work with GNU tar, but that is ok.
>
Not if that would be done unconditionally (we don't want to require GNU tar);
but if you are proposing we should make it possible to pass extra arguments
to tar invocations, or to customize them in other ways, than I agree that
would be a nice feature to have.

OTOH, what about distribution "tarballs" in '.zip' format?  They don't
use tar at all ...  Time to deprecate them maybe?  Is anybody actually
using them?  And while at it, what about the even more obscure 'shar'
format?

> What worked for me is to override the definition of am__tar, like this in
> Makefile.am:
>   am__tar = tar --exclude-vcs --format=ustar -chf - "$$tardir"
> 
> Except I don't really want to put this into Makefile.am.  Happily, this
> also worked from the command line:
>   $ env am__tar='tar --exclude-vcs --format=ustar -chf - "$tardir"' make dist
> 
> For that matter, it would be nice if am__tar provided a way to pass
> arbitrary extra options.  Perhaps include something like
> $(AM_TAR_USER_OPTIONS) in the definition? 
> 
> Equivalently, provide a way to override the name "tar", as in
> $(AM_TAR_PROGRAM)?  That might be simplest of all.
>
Yes.  Maybe (just thinking aloud here) it could also help us to eventually
dispense with the horrible "tar-v7", "tar-ustar" and "tar-pax" options.
More stuff pushed at 'make dist' time rather than at configure time; and
less need to be "automagical", since 'dist' is a maintainer target ...

> Along those lines, it would be nice if Automake always used the -chf
> style above.  In some distributions' Makefiles I've seen "chf" (didn't
> look into why);
>
"Historical reasons" would be my first guess.

> that prevents adding options though, due to the vagaries
> of tar command line parsing which we all know.  I have the impression
> that every tar (except maybe really ancient ones, can't remember, but we
> don't care) supports the -style.
>
It would be nice to verify this claim on as much systems as possible
(ignoring museum pieces, of course).

> Sorry for the brain dump of all these possibilities, but wdyt?
> 
See above :-)

Thanks,
  Stefano