On 01/04/2012 08:57 PM, Jim Meyering wrote: > (latest from git/master) > I just ran the test suite using the latest and now we're down to 5 failures! > > # TOTAL: 2478 > # PASS: 2382 > # SKIP: 61 > # XFAIL: 30 > # FAIL: 5 > # XPASS: 0 > # ERROR: 0 > > $ grep '^FAIL:' tests/test-suite.log > FAIL: depmod > FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake > FAIL: depmod.tap 84 - tru64 [absolute VPATH] make & remake > About these failures, see also: <http://lists.gnu.org/archive/html/automake-patches/2011-05/msg00019.html>
> Started looking, and this one may be easy to fix: > > make[1]: Leaving directory > `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src' > make[1]: Entering directory > `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d' > make[1]: Nothing to be done for `all-am'. > make[1]: Leaving directory > `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d' > + make clean > Making clean in src > make[1]: Entering directory > `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src' > .deps/foo.Po:3: *** missing separator. Stop. > make[1]: Leaving directory > `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src' > make: *** [clean-recursive] Error 1 > + result_ 'not ok' 'tru64 [long VPATH] make & remake' > + set +x > not ok 50 - tru64 [long VPATH] make & remake > FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake > + cd /h/j/w/co/automake/tests/depmod.dir > + not am_keeping_testdirs > > Once you see the contents of the offending foo.Po file: > (the "\:" on line 3 is the obvious culprit) > > $ cat tests/depmod.dir/tru64-long.d/src/.deps/foo.Po > foo.o: ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \ > ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h > ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \: > ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h: > > tap 84 fails for the same reason. > The fact is that these failures (as we can experience them, at least) only happen when we are *forcing* the use of the tru64 depmode *to gcc* (which obviously isn't really meant nor expected to handle it); OTOH, the failures do *not* happen with the Sun C Compiler (5.9 on Solaris 10). So the real question is: do such failures take place with the Tru64 compiler? If yes, we really have a bug to fix; if not, the failure is merely a consequence of our messing with forced depmodes, and the correct fix is to SKIP the affected tests. Unfortunately, I don't have access to a Tru64 system, so I can't do the testing myself. Regards, Stefano
