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
executions):
11: autoconf: forbidden tokens, basic FAILED (tools.at:481)
So far I got it on aarch64 and s390x. Timing issue maybe ?
Yeah, this one is <https://savannah.gnu.org/support/?110986>. 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/tools.at, 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 configure.ac
and the first autoconf run, and that should ensure that the autom4te
cache will be newer than configure.ac 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/local.at (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 configure.ac and that the cache is newer.
-- Jacob
