LFS-7.5 util-linux `make check` не работает

Когда я запускаю make check in util-linux , он не говорит:

3 теста 127 FAILED

Согласно журналам испытаний 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: незаконное значение года: '1234567890123456789': численный результат вне диапазона
cal: незаконное значение года: '1234567890123456789': численный результат вне диапазона
FAILED (cal / bigyear)

Это тот же вопрос, что и в списке рассылки. Но тот, кто задал этот вопрос, писал сценарий, который привел к вышеупомянутой ошибке, и он говорит, что он будет ждать patch , который исправляет эту проблему.

Будет ли это негативно влиять на мою сборку LFS позже?

ПРИМЕЧАНИЕ. Я пытаюсь создать 32-bit lfs систему 32-bit lfs на Linux Mint 17 32bit

Будет ли это негативно влиять на мою сборку LFS позже?

Я не представляю, как. Во-первых, cal – это приложение для конечных пользователей, чем ничто другое не нуждается или зависит от него. Даже если это необходимо в какой-то момент, оно все равно будет соответствовать критериям, указанным POSIX, независимо от этого конкретного недостатка:

Утилита cal должна записывать календарь на стандартный вывод, используя юлианский календарь для дат с 1 января 1 по 2 сентября 1752 года и григорианский календарь для дат с 14 сентября 1752 года по 31 декабря 9999 года, как если бы был принят григорианский календарь 14 сентября 1752 года.

Год 1234567890123456789 находится за пределами этого диапазона. Как обсуждалось в потоке, это происходит в 32-битных системах, потому что некоторые стандартные типы библиотек меньше, чем на 64-битных; в тестовом журнале LFS, который вы связывали без сбоя, в URL- core2duo есть core2duo поэтому, скорее всего, это из 64-битной системы. В этом отчете есть 6 тестов для cal , «Year 1234567890123456789», являющихся одним из них, и у вас есть разумное объяснение сбоя. Предполагая, что вы начинаете с последнего источника util-linux, очевидно, что исправление для этого не считалось особо актуальным; вы можете попробовать и отследить это, но TBH, я бы не стал беспокоиться.