On 07/09/2012 07:04 PM, Max Horn wrote:
> Hi there,
>
Hi Max.

> I am currently looking into packaging automake 1.12.1 for
> Fink <http://www.finkproject.org/> on Mac OS X 10.7.
> Doing that, several test suite failures popped up, which
> I am now working through to resolve.
>
In the meantime, could you please post the 'test-suite.log' file,
for reference?  Thanks.

> The first one is t/silentcxx-gcc.sh failing.
> Note that t/silentcxx.sh incorrectly (!) succeeds.
> 
> There are two problems here:
> 
> 1) The C++ compiler from Sun Studio is named "CC". This caused
> t/silentcxx.sh to fail, which was fixed with commit ad5d0be02d
> in the autonconf
>
s/autoconf/automake/ I guess.

BTW, the problem you are reporting is similar to the one reported
in bug#10766 by Peter Rosin (which I'm thus CC:ing):
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>

> git repository. The same fix also needs to be applied to
> t/silentcxx-gcc.sh.
>
See if the attached patch solves the issue for you.  Ideally, it
should also fix bug#10766; Peter, could you give it a try?

> 2) But actually I am happy this was there, because otherwise
> I wouldn't have detected this second, more serious bug: On
> Mac OS X, automake 1.12.1 incorrectly thinks the C++ compiler
> is named CC (when really it should be clang++, c++ or g++).
> This is because (a( OS X by default uses a case in-sensitive
> file system, and so "CC" is equivalent to "cc", and (b) the
> automake 1.12.1 code for some reason duplicate some autoconf
> code for detecting the C++ compiler, but changed this code,
> breaking it.
>
It's not actually broken, it's just that, while Autoconf-generated
configure scripts prefer GCC over other compilers, the Automake
configure script does the other way round, to try to enhance coverage
in its testsuite.  Note that this inverted logic is only applied to
the configure of Automake itself, and *not* to those of the packages
using configure (this is very important!).

> To quote automake's configure.ac:
> 
> <BEGIN QUOTE>
> # The list of C++ compilers here has been copied, pasted and edited
> # from 'lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution.
> # 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 CC FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])],
>   [CXX=false; _AM_SKIP_COMP_TESTS([C++])])
> <END QUOTE>
> 
> But this is what my version of c.m4 contains:
> <BEGIN QUOTE>
>     AC_CHECK_TOOLS(CXX,
> 		   [m4_default([$1],
> 			       [g++ c++ gpp aCC CC cxx cc++ cl.exe FCC KCC RCC xlC_r xlC])],
> 		   g++)
> <END QUOTE>
> i.e. the order of the compilers has been changed, and this causes the breakage above. 
> 
> I wonder whether this different order of compilers is intentional --
>
Yes, see above.

> and why this is duplicated in automake in the first place?
> The comment in configure.ac just says that the list was duplicated,
> not *why*.
>
Because we need to have the entries of the list sorted in a different
order than the one they are in Autoconf.

> It would be nice if it could be extended to explain just that by somebody
> who knows :).
>
The explanation is already given in the comments above:

  # Prefer generic compilers to GNU ones when possible.  This will ensure
  # more testsuite coverage "in the wild".
  # Note that we don't look for the MSVC C/C++ compiler here.  This is
  # deliberate; for more discussion and rationale, see:
  # <http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00130.html>

Thanks,
  Stefano