计算机时钟设为过去时间时configure为何无限循环？

1. 编译异常的核心原因：文件时间戳超前 #

没错，就是你从其他系统传输过来的源代码文件修改时间远晚于当前系统时钟导致的。Autotools（autoconf/automake）的构建逻辑严重依赖文件时间戳：它会对比configure.ac/Makefile.am这类源文件和生成的configure/Makefile.in等构建脚本的时间戳，判断是否需要重新生成构建文件。当系统时钟比源文件修改时间慢20多万秒时，脚本会认为源文件“刚被修改过”，必须重新生成所有构建相关的文件。

2. 无限循环生成进程的原因 #

Autotools的构建链存在循环依赖关系：

• configure脚本由autoconf从configure.ac生成
• configure运行时会检查Makefile.in是否过时，而Makefile.in又由automake从Makefile.am生成

当系统时钟异常时，每次运行configure都会触发automake重新生成Makefile.in，但新生成的Makefile.in的时间戳会被系统的慢时钟标记为“过去的时间”——下一次configure检查时，又会觉得它比Makefile.am旧，再次触发重新生成。这种循环会不断fork出configure和make进程，直到时钟被修正或者资源耗尽。

Autotools默认不会直接报错退出，是因为它的设计初衷是自动同步构建脚本与源文件的变更，方便开发者修改源文件后无需手动重新生成构建脚本。但在时间戳异常这种极端场景下，这种自动逻辑就变成了死循环。

3. 关于Autotools的复杂度与“开发者踩坑” #

这不是Autotools的bug，也不是nano开发者的失误。Autotools的复杂度确实高，因为它要兼容数十种不同的Unix-like系统、处理各种版本的编译器和工具链，时间戳检查是其中一个基础但容易被忽略的细节。

开发者在正常开发环境中不会遇到时钟偏移好几天的情况，所以不会特意针对这种极端场景做防御性处理。毕竟没人会主动在时钟严重错误的系统上编译软件，这属于边缘场景的触发问题，而非Autotools本身的设计缺陷。

内容的提问来源于stack exchange，提问作者aphid