当我跑make check进去的时候实用程序Linux，它失败了：
3 次测试 127 次失败
根据LFS-7.5 测试日志成立这里, 2 次测试失败，这是可以接受的。但我的cal命令在测试时失败了big/year，它说：
cal：年份 1234567890123456789 ...cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789 ': 数值结果输出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
cal：非法年份值：'1234567890 123456789 '：数值结果超出范围
cal：非法年份值：'1234567890123456789'：数值结果超出范围
失败（cal/bigyear）
这与邮件列表中发布的问题相同这里。但是这里提出问题的人正在编写一个独立的脚本，这导致了上述错误，他说他会等待patch，它会纠正这个问题。
会对我产生负面影响吗线性FS以后再建？
笔记：我正在尝试构建一个32-bit lfs系统Linux 薄荷 17 32 位
答案1
它会对我以后的 LFS 构建产生负面影响吗？
我无法想象如何。一方面，cal它是最终用户应用程序，没有其他应用程序可能需要或依赖。即使在某个时候需要，它仍然会满足POSIX 指定的标准不管这个特殊的缺陷如何：
cal 实用程序应将日历写入标准输出，对于从 1752 年 1 月 1 日到 9 月 2 日的日期使用儒略历，对于从 1752 年 9 月 14 日到 9999 年 12 月 31 日的日期使用公历，就好像采用了公历一样1752 年 9 月 14 日。
年份 1234567890123456789 不在该范围内。正如线程中所讨论的，它发生在 32 位系统上，因为某些标准库类型比 64 位系统上的小；您链接的没有失败的 LFS 测试日志core2duo位于 URL 中，因此很可能来自 64 位系统。该报告中有 6 个测试cal，“年份 1234567890123456789”就是其中之一，并且您对失败有合理的解释。假设您从最新的 util-linux 源开始，显然这个补丁并不是特别紧急；你可以尝试追踪它，但说实话，我不会打扰。