내가 뛰어 make check들어왔을 때유틸리티Linux, 다음과 같이 실패합니다.
3번의 테스트와 127번의 실패
~에 따르면LFS-7.5 테스트 로그확립된여기, 2개의 테스트가 실패했으며 이는 허용 가능합니다. 하지만 cal테스트할 때 내 명령이 실패합니다 big/year. 다음과 같이 표시됩니다.
cal: 연도 1234567890123456789 ...cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다.
cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다.
cal: 잘못된 연도 값: '1234567890123456 789': 숫자 결과 출력 범위
cal : 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다.
cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다.
cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다. 범위
cal: 잘못된 연도 값: '1234567890123456789' : 숫자 결과가 범위를 벗어났습니다.
cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과
가 범위를 벗어났습니다. cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다
. : 잘못된 연도 값: '1234567890 123456789': 숫자 결과가 범위를 벗어났습니다
. cal: 잘못된 연도 값: '1234567890123456789': 숫자 결과가 범위를 벗어났습니다
(cal/bigyear).
메일링 리스트에 올라온 질문과 동일합니다여기. 그런데 여기 질문을 하신 분은 위와 같은 오류를 일으키는 별도의 스크립트를 작성하고 계시며 기다리시면 patch문제가 해결될 것이라고 하셨습니다.
나에게 부정적인 영향을 미칠까요?선형 FS나중에 빌드하시겠습니까?
노트:32-bit lfs시스템을 구축하려고 합니다.리눅스 민트 17 32비트
답변1
향후 LFS 빌드에 부정적인 영향을 미치나요?
어떻게 될지 상상할 수 없습니다. 한편으로는 cal다른 응용 프로그램이 필요하지 않거나 의존할 수 없는 최종 사용자 응용 프로그램입니다. 어느 시점에 필요하더라도 여전히 만족할 것입니다.POSIX 지정 표준이 특정 결함에 관계없이:
cal 유틸리티는 1752년 1월 1일부터 9월 2일까지의 날짜에는 율리우스력을 사용하고 1752년 9월 14일부터 9999년 12월 31일까지의 날짜에는 그레고리력을 사용하여 마치 그레고리력 9월을 사용하는 것처럼 표준 출력에 달력을 작성해야 합니다. 1752년 14일.
1234567890123456789 연도가 이 범위에 포함되지 않습니다. 스레드에서 설명한 대로 표준 라이브러리 유형 중 일부가 64비트 시스템보다 작기 때문에 이 문제가 발생합니다. 실패하지 않는 LFS 테스트 로그는 core2duoURL에 있습니다. 64비트 시스템일 가능성이 높습니다. 보고서에는 6개의 테스트가 있으며 cal"연도 1234567890123456789"가 그 중 하나이며 실패에 대한 합리적인 설명이 있습니다. 최신 util-linux 소스에서 시작한다고 가정하면 분명히 이 패치가 특별히 긴급하지는 않지만 추적해 볼 수는 있지만 솔직히 신경쓰지 않을 것입니다.