[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Automake 1.8.2 released

From: Alexandre Duret-Lutz
Subject: Re: GNU Automake 1.8.2 released
Date: Tue, 13 Jan 2004 17:25:33 +0100

On Tue, Jan 13, 2004 at 02:59:23PM +0000, Lars Hecking wrote:
> Alexandre Duret-Lutz writes:
> > I'm embarassed to announce the release of Automake 1.8.2.
>  And rightly so ;-)
>  It fails two tests here on Solaris 9 - acloca14.test and conflnk3.test.

Thanks for the report.  These look like harmless spurious failures.

Please people, do send such bug reports to address@hidden not to
the main list.  This is what `make check' asks, this is what the
annoncement text asks, this is also what the annoncement headers ask.
I don't know what else I can do (suggestions welcome).

> ...checking for a BSD-compatible install... /usr/local/gnu/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> configure: creating ./config.status
>  /bin/bash ./config.status
> config.status: creating Makefile
> make: Nothing to be done for `all'.
> aclocal.m4 stamp differ: char 42, line 1
> FAIL: acloca14.test
>  If this test does what I think it does (comparing a generated aclocal.m4
>  with a non-generated) it fails because the former was generated by the
>  installed version of aclocal, and the actual difference is caused by the
>  version strings inserted by aclocal.

Unless the suggestion below makes sense, could you send the full
output of the test?  I don't have enough context here and would also
like to see the very first line, which shows $PATH.  The point is that
PATH is sets so that the locally built aclocal occurs before any
installed version.

If aclocal.m4 and stamp differ by the version string, then it means PATH
was reset at some point.  It looks like the same bug as
(i.e., a shell setup that mistakenly resets PATH in non-interactive shells),
the only difference being that you already have an automake-1.8 installed.

>  I _think_ the other test fails because it uses test -e, which is not
>  supported in Solaris' /bin/sh:

Surely that's it.  I'll change this test to skip platforms where
`test -e' does not work.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]