AT_MTIME_DELAY not working? (was: Re: [platform-testers] autoconf-2.72e released [release candidate])

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


Zack Weinberg wrote:
On Thu, Dec 21, 2023, at 3:27 AM, Frederic Berat wrote:
On Wed, Dec 20, 2023 at 10:22 PM Zack Weinberg <zack@xxxxxxxxxxxx> wrote:
I also get this one that fails once in a while (3 failures out of 12

 11: autoconf: forbidden tokens, basic               FAILED (

So far I got it on aarch64 and s390x. Timing issue maybe ?

Yeah, this one is <>.  We're expecting
the second of two autoconf runs in quick succession to pull from a cache and
sometimes it doesn't.  I get it reproducibly on one of my test machines and
I may try to pin it down later today, but I don't think it's worth holding
the release for.

Looking at tests/, I think I found the problem: the generated configure script is the /output/ from autoconf; there is no reason for its timestamp to matter.

In either case, there is an AT_MTIME_DELAY between writing and the first autoconf run, and that should ensure that the autom4te cache will be newer than and "touch configure" should be irrelevant. If autom4te is testing some timestamp relationship other than the cache and its sources, then we have found a bug in autom4te.

A quick look at tests/ (on Git master) suggests a possible merge error probably unrealated to this issue: the AS_ECHO on line 222 that announces the detected mtime resolution is in the subshell that verifies that required programs are available instead of the main level just after the "rm -f conftest.ts?" on line 170 that cleans up the timestamp test files.

I suggest revising AT_MTIME_DELAY to actually create two files and loop touching one of them until the timestamps differ. Something like: (untested)

touch at_delay.tsn at_delay.tso
until test at_delay.tsn -nt at_delay.tso;
do sleep $at_ts_resolution; touch at_delay.tsn; done
rm at_delay.ts?

This would ensure that the system clock has actually advanced by at least one mtime tick before execution continues past AT_MTIME_DELAY. The issue you are seeing looks like sleep(1) is not entirely reliable. (!!!) If AT_MTIME_DELAY can be made reliable, the AT_MTIME_DELAY/"touch configure" block in that test should be unneeded, with its explanatory comment moved up to the first AT_MTIME_DELAY in that test with a change to mention and that the cache is newer.

-- Jacob

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux