2

When I run make check in util-linux, it fails saying:

3 tests of 127 FAILED

According to LFS - 7.5 test logs found here, 2 tests fail and that is acceptable. But my cal command fails while testing for big/year and it says:

cal: Year 1234567890123456789 ...cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
FAILED (cal/bigyear)

This is the same question as posted in mailing-list here. But the person who asked the question here was writing an independent script, which resulted in the above mentioned error and he says that he will wait for a patch, which rectifies this problem.

Will it have a negative effect on my LFS build later on?

NOTE: I am trying to build a 32-bit lfs system on Linux Mint 17 32bit

2

Will it have a negative effect on my LFS build later on?

I can't imagine how. For one thing, cal is an end user application than nothing else is likely to need or depend upon. Even if it is required at some point, it will still meet the criteria specified by POSIX regardless of this particular flaw:

The cal utility shall write a calendar to standard output using the Julian calendar for dates from January 1, 1 through September 2, 1752 and the Gregorian calendar for dates from September 14, 1752 through December 31, 9999 as though the Gregorian calendar had been adopted on September 14, 1752.

The year 1234567890123456789 is outside of that range. As discussed in the thread, it happens on 32-bit systems because some standard library types are smaller than they are on 64-bit; the LFS test log you linked without the failure has core2duo in the URL so is most likely from a 64-bit system. There are 6 tests in that report for cal, "Year 1234567890123456789" being one of them, and you have a reasonable explanation for the failure. Presuming you are starting from the latest util-linux source, obviously the patch for this was not considered particularly urgent; you could try and track that down but TBH, I would not bother.

  • 1
    I suppose it could if something first wants cal to pass such a test, but again, it is very hard to see what would require it in the first place. If such a problem does happen, it should be explicit, so at that point you can try and find the patch, rebuild cal (you won't have to do all of util-linux), file a further bug report, etc. If I could place a bet here, though, I'd put a lot against that ever happening. It's a very trivial issue. – goldilocks Jul 3 '14 at 7:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.