Re: rhel8 test failure confirmation?

Bogdan <[email protected]>
Newsgroups gmane.comp.sysutils.automake.general
Message-ID <[email protected]>
Karl Berry <[email protected]>, 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.