Сборка под x86_64-uClibc-static: продолжаются танцы с бубном

С e2fsprogs вообще непонятно что делать, а читерствовать (то есть скачать прекомпилированные исполняемые файлы) я принципиально не желаю. Ни с uClibc, ни с dietlibc их собрать пока не удалось, хотя поддержка собираемости под dietlibc заявлена прямым текстом. И даже опция в конфигурялке есть: --with-diet-libc.

Собственно, под dietlibc сборка доходит почти до конца, прекращаясь следующим образом:

make[2]: Вход в каталог `/usr/src/e2fsprogs-1.41.9/misc'
  CC util.c
util.c: In function 'check_plausibility':
util.c:83: error: storage size of 's' isn't known
make[2]: *** [util.o] Ошибка 1
make[1]: *** [all-progs-recursive] Ошибка 1
make: *** [all] Ошибка 2

Строки 83-85 этого файлы выглядят так:

	struct stat64 s;

	val = stat64(device, &s);

То есть, происходит объявление переменной s типа struct stat64 БЕЗ ИНИЦИАЛИЗАЦИИ, в результате размер самой структуры неизвестен. А автор dietlibc говорит прямым текстом, что его библиотека не содержит автоматических инициализаторов, чтобы минимизировать количество кода. Поэтому данный фрагмент ВПРИНЦИПЕ не может быть собран с dietlibc!

С uClibc всё ещё печальнее: сборка прерывается ещё раньше из-за переопределения «встроенных» типов __s8, __u8, __s16, __u16, __s32, __u32, __s64, __u64. Закомментировать в соответствующем инклюде объявление этих типов можно, но это не помогает, сборка всё равно прерывается с ещё более непонятными ошибками.

Вряд ли это так и должно быть. Раз задекларирована совместимость с dietlibc, то и собираться всё должно с dietlibc, так что код, скорее всего, должен быть пофиксен. Но кто бы могог мне сделать багрепорт, по-аглицки изъясняться не умею, токмо читаю :-(

я так и не понял цели этого квеста.

Скаал самый послежний снапшот, наивно полагая, что там как-то пофиксили проблемы с собираемостью. Фиг там. С dietlibc по-прежнему компиляция останавливается на том же самом месте: не хочет собирать misc/util.c. Потом пробую с uClibc. Опять та же ошибка с переопределением встроенных целочисленных типов разной разрядности, но компиляция идёт немного дальше, запинаясь на файле filefrag.c. Начал отслеживать инклюды, дошёл до lib/ext2fs/fiemap.h, который, сопсна, и включал
. И чуть ниже переопределял типы от __s8 и до __u64. Причём, ни filefrag.c, ни какой-либо другой сопутствующий код не использует linux-специфичных типов переменных. Тогда я решил просто исключить соответствующую строчку из fiemap.h. Но поскольку я не знаю и не могу знать, как её наличие или отсуствие влияет на собираемость с другими *libc, то создал условное исключение:

#ifndef __UCLIBC__
 #include <linux/types.h>
#endif

После чего всё прекрасно собралось, проинсталлировалось и даже заработало... кроме uuidgen, который стабильно оставлял core. Собирать с дебаггером и выяснять, где происходит косяк, я не стал -- всё равно не умею отправлять багрепорты :-( Поэтому я сделал так: просто make clean, переконфигурация обратно под dietlibc, make. Потом

user# cd util
user# make uuidgen; strip ./uuidgen

uuidgen собрался и работал. Переместил я его в /bin вместо его кривого брата-близнеца, на этом работа с e2fsprogs была завершена.

После этой маленькой победы были без серьёзных проблем собраны все «штатные» интерпретаторы: sed (провалил 1 тест), libsigsegv (прошло все тесты), gawk (6 тестов провалено), bison-2.4 (17 тестов провалено), flex (7 тестов провалено).

Дальше решил собрать procps-3.2.8. Сборка до конца не проходит (буду разбираться), а то, что собралось, работает неправильно. В частности, w показывает, что в системе залогинено 0 пользователей. Где-то читал, что на 64-битных системах формат файлов /var/run/utmp и /var/run/wtmp немного отличается от того, что на 32-битных системах, и говорят, что в предпоследнем снапшоте uClibc уже есть фикс и work-around. Буду разбираться дальше.