automake
[Top][All Lists]
Advanced

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

Re: rhel8 test failure confirmation?


From: Bogdan
Subject: Re: rhel8 test failure confirmation?
Date: Sun, 5 Mar 2023 22:31:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

Karl Berry <karl@freefriends.org>, Sat Mar 04 2023 00:00:56 GMT+0100 (Central European Standard Time)
     Note that 'config.h' is older (4 seconds) than './configure', which
     shouldn't be the case as it should get updated with new values.

Indeed. That is the same sort of thing as I was observing with nodef.
But what (at any level) could be causing that to happen?
Files just aren't getting updated as they should be.

I haven't yet tried older releases of automake to see if their tests
succeed on the systems that are failing now. That's next on my list.

[...]


Another tip, maybe: cache again. When I compare which files are newer than the only trace file I get in the failing 'backcompat2' test ('autom4te.cache/traces.0'), I see that 'configure.ac' is older than this file in the succeeding run, but it's newer in the failing run. This could explain why 'configure' doesn't get updated to put new values in config.h (in my case) - 'autom4te' thinks it's up-to-date.
 The root cause may be in 'autom4te', sub 'up_to_date':

  # The youngest of the cache files must be older than the oldest of
  # the dependencies.
  # FIXME: These timestamps have only 1-second resolution.
  # Time::HiRes fixes this, but assumes Perl 5.8 or later.

(lines 913-916 in my version).

Perhaps 'configure.ac' in the case that fails is created "not late enough" (still within 1 second) when compared to the cache, and the cached values are taken, generating the old version of 'configure' which, in turn, generates old versions of the output files.

 Still a guess, but maybe a bit more probable now.

Does it work when you add '-f' to '$AUTOCONF'? It does for me - again, about 20 sequential runs of the same set of tests and about 5 parallel with 4 threads. Zero failures. I'd probably get the same result if I did a 'rm -fr autom4te.cache' before each '$AUTOCONF' invocation.

If it does work for you, then maybe it would be better to add '-f' to the 'AUTOCONF' variable where it's defined? Tests with a single '$AUTOCONF' invocation won't notice (they will create their cache anyway), while tests with multiple calls can maybe get fixed all at once.

And I take back that the problem doesn't arise when I call the single test. I just wasn't "lucky enough". Got a failure now (without the fix), in the 7th attempt, while 40 or 60 (I did batches of 20) earlier succeeded (with the fix, of course).

So, maybe it's not a problem of a NEW system by itself, just a FASTER system + 1-second resolution in 'autom4te'.

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org




reply via email to

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