mainAutoconf - Support: sr #110986, "autoconf: forbidden tokens,...

 
 

sr #110986: "autoconf: forbidden tokens, basic" testsuite failure on some systems

Submitter:  Zack Weinberg <zackw>
Submitted:  Wed 20 Dec 2023 02:11:14 PM UTC
   
 
Priority:  * 3 - Release N+1 Severity:  2 - Minor
Status:  Need Info Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 21 Dec 2023 09:15:46 PM UTC, comment #2: 

This is a regression caused by commit
<https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=713d9822bbfb2923115065efaefed34a0113f8a1>,
"Fix timing bug on high-speed builds".  That commit changed autom4te's logic for deciding whether its output file is newer than its cache file: if their modification times are equal, the output is considered out of date.  Since both files are created in quick succession, on file systems with coarse timestamps (1 or 2s resolution), it is very easy for their modification times to be equal.

For 2.72 I'm going to make the test suite adjust the modification time of the file that's supposed to be newer, but I'm also going to leave this bug open, because autom4te ought to be able to ensure that the cache file is always observed to be older than the output.

Zack Weinberg <zackw>
Group administrator
Wed 20 Dec 2023 02:13:07 PM UTC, comment #1: 

The worst practical consequence of this is only that we may run M4 more often than we needed to, but I'm still marking this as desirable to fix soon if we can, just because it looks bad to have a known failure so early in the test suite.

Zack Weinberg <zackw>
Group administrator
Wed 20 Dec 2023 02:11:14 PM UTC, original submission:  

Observed by me on at least x86_64-netbsd9 and sparc64-solaris10: the "autoconf: forbidden tokens, basic" test fails because the second invocation of autoconf prints the same "possibly undefined token" error messages as the first invocation, contrary to the test's expectations.  This is probably more fallout from the sub-second timestamp changes: the second invocation is supposed to pull 'configure' from cache and not re-run M4.  Unfortunately, the second invocation of autoconf clobbers the mtime of all the files involved, making it difficult to figure out exactly what went wrong after the fact.

Zack Weinberg <zackw>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by zackw (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-20 zackw Priority5 - Unprioritized 3 - Release N+1

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code