непонятное при сборке toolchain'а по LFS

если что, сборка тулчейна запускается запуском отдельного скрипта, в котором указан source необходимого профайла шелла, который уже запускает сборку используя PM CRUX'а и отдельно созданные порты. а переменная toolchain у меня — это так назвал переменную lfs= из книги

в LFS-9.1 в главе 4.2 ещё есть ln -s "$LFS/tools" / а в 10.0 уже нет. глава 4.4 тоже отгличается, в последней версии там странное назначение PATH: [[ ! -L /bin ]] && PATH="/bin:$PATH" объясните кто-нибудь

да, давно тулчейн не собирал... там какие-то серьёзные изменения в процессе сборки, надо вникать...

Похоже, что make DESTDIR=$toolchain install дает такой эффект.

не, там в CRUX'е там везде make DESTDIR=$PKG install. но там не в этом дело было, там до инсталл не доходило даже. там на одну из промежуточных директорий, у other прав не хватало... ща gcc pass1 уже собирается

долго думал в чём дело. оказывается действительно из-за того что указывается --prefix=$LFS/tools, а потом идёт make DESTDIR=$PKG install, а потом я делал pkgadd -r <тут ещё раз указывается $LFS>. из-за этого директории дублируются. прмшёл к выводу, что нужно пропатчить pkgadd, добавив ключ наподобие -r только с той разницей что будет задаваться только путь к новой db ПМ'а, а не rootfs (корень окажется старым) и тогда binutils pass1 и gcc pass1 окажутся в правильных директориях

Зачем пакетить промежуточные сборки? Опакетить весь тулчейн за один проход. Он жеж временный и будет снесен при сборке самого LFS’а, т.к. его файлы будут перезаписаны в 8ом разделе.

не знал, что его файлы будут перезаписаны... я просто хочу создать тулчейн, который просто лежал бы на диске, и, когда надо, использовал бы его для соэдания новых сборок. можно ли так сделать, чтобы он остался, как конечный инструмент?

не знал, что его файлы будут перезаписаны.

Смотри куда ставятся софтины в разделах 6 и 8.

ИМХО, самое простое - собрать до перехода в в chroot, далее

tar cJf toolchain.tar.xz $LFS.

Рядом кинуть скрипт, который выставляет переменные окружения и готовит chroot.

я раньше делал скрипт, который одним скриптом тулчейн собирает по книге без всякого пакетного менеджера, но тут подумал, что лучше было бы опакетить сборку тулчейна, учитывая что используется такой дистр как CRUX. а вот и не знаю теперь как лучше.

Смотря куда ставятся софтины в разделах 6 и 8.

а как можно поменять, как задать правильно все эти --prefix и --with-sysroot?

ИМХО, самое простое ...

а может, так и сделаю, если не найду ничего лучше...

лучше было бы опакетить сборку тулчейна

Чем лучше? По итогам всех мытарств из 5, 6 глав ты получишь корневую ФС своего нового дистрибутива, в которую чрутнешься и будешь пилить дистрибутив своей мечты. Где пакет будет хранить эту ФС в основной системе и нужно ли ее там держать?

а как можно поменять, как задать правильно все эти –prefix и –with-sysroot?

Указать свой путь. Если таки решишься пакетить, то для pass1 (всего того, что попадет в tools) можно указать –prefix=$BUILD/tools, где $BUILD - это директория в твоей сборочной системе, где происходит сборка пакета. Да, всё с DESTDIR=$LFS надо будет менять на DESTDIR=$PACKAGE_DIR (т.е. куда ставятся файлы, попадающие в пакет). Это в общих чертах, не знаком со сборочной системой CRUX’а.

Допом погляди CROSS LFS, как вообще кросс-сборка устроена. В LFS все эти pass1 (кросс-компилятор для x86 на x86) по сути костыли, чтобы не подцепились либы или ещё что из основной системы

Зачем пакетить промежуточные сборки? [...] файлы будут перезаписаны в 8ом разделе.

в 6 и 7 разделе есть программы, например coreutils, которые перезапишутся в 8ом, но как быть, если в конечной системе (и для её сборки) я планирую использовать пакетный менеджер CRUX'а, а в нём недопускается установка файлов, если таковые уже имеется (можно использовать ключ --force, но так делать не надо)? можно ли для всего в 5, 6, 7 использовать --prefix=$LFS/tools, с целью получить в конце полностью чистую систему без пересекающихся файлов?

указать --prefix=$BUILD/tools, где $BUILD - это директория в твоей сборочной системе, где происходит сборка пакета.

вот это вот не понял, что за директория? это та что в книге mkdir build; cd build делаеися для каждой сборки, или нет?

и да, судя по всему, придётся НЕ пакетить тулчейн...

можно ли для всего в 5, 6, 7 использовать --prefix=$LFS/tools

хотя, возможно, это даже не обязательно, т.к. у pkgadd есть ключ --root <path> для задания rootfs для установки пакета, но вопрос всё-равно открыт

можно ли для всего в 5, 6, 7 использовать –prefix=$LFS/tools, с целью получить в конце полностью чистую систему без пересекающихся файлов?

Не стоит. В /tools собирают минимум, необходимый для сборки libc, не более того. Многие софтины ожидаются по стандартным путям, иногда захардкоженным.

Цель сборки ЛФСа - получить минимальную систему, способную к пересборке и дальнейшему расширению. 5, 6, 7 - это ВРЕМЕННЫЕ тулзы, собранные в минимальной комплектации. В 8 они перезаписываются финальными версиями и их файлов не останется.

Когда собирал свой LFS (с RPM5:)), добавил ПМ и его зависимости после сборки системы, далее собрал пакеты и накатил их на систему, чтоб появились записи в базе ПМа. Файлы-то по сути остались неизменными.

Если очень хочется некой «чистоты», то далее рассматриваем LFS систему как временную. Берем несколько десятков пакетов с предыдущего шага и накатываем на нужный раздел с помощью –root=<здесь будет мой линукс> c переходом в chroot и настройкой. Так ты пройдешь путь разрабов дистрибутивов. Потом тебя ждут вопросы создаания чистого сборочного окружения, сопровождения этой прорвы пакетов, но не будем о грустном.

вот это вот не понял, что за директория? это та что в книге mkdir build; cd build делаеися для каждой сборки, или нет?

А как твой ПМ собирает пакеты? Распаковывает исходник во временную директорию (как она зовется смотрим в документации), собирает его, ставит получившееся в другую временную директорию через DESTDIR, пакует это все в архив.

и да, судя по всему, придётся НЕ пакетить тулчейн…

Именно, ибо а) это одноразовый пакет, который не нужен в основной системе; б) в сборочный скрипт пакета придется упихать полкниги.

и всё-таки, не совсем понятно с --root. если я соберу минималистичный тулчейн по LFS, потом буду собирать из него конечную систему в --root=/mnt, как в новых пакетах будут прилинковываться нужные для core CRUX'а нужные библиотеки, ведь настоящий корень вовсе не /mnt, а тот в котором тулчейн? как делать чтобы при сборке конечной системы линковалось с будущего корня а не из тулчейновского. нужно ведь всё грамотно делать и по-чистоте...

Не стоит. В /tools собирают минимум, необходимый для сборки libc, не более того. Многие софтины ожидаются по стандартным путям, иногда захардкоженным.

Не вижу другого выхода. Почитал CLFS, и там все tools и cross-tools так и собираются. там для компиляции прописывается LDFLAGS="-Wl,-rpath,/cross-tools/lib". но там , правда, дальше в 8.6 создаются не нужные мне ссылки...

Как быть, если по фэн-шую надо запускать pkgadd без ключа --force, т.е. не перезаписывать файлы которые уже есть, и, в то же время при сборке с помощью tools конечной системы при компилчции каждого порта пакетным менеджером CRUX'а должны подлинковываться необходимые библиотеки из нового корня и поэтому для установки каждого нового порта ключ --install-root= не подходит? как это всё осуществить?

есть одна мысль: собрать тулчейн как по книге, туда же установить пакетный менеджер CRUX'а, потом чрутнувшись собрать там core с флагом --force, а затем уже распаковать все готовенькие тарболы в другую диру ключём --install-root=, но уже без --force

В 8 они перезаписываются финальными версиями и их файлов не останется

а что если версии glibc в тулчейне и в конечной системе отличаются?

• собрал временные тулзы;
• собрал постоянные;
• чрутнулся и собрал остальное (получилось core, essential, в разных дистрах по разному зовется);
• собрал пакетный менеджер с зависимостями;
• пишешь сборочные скрипты пакетов и собираешь пакеты;
• ставишь пакеты в /mnt/куда-надо.

Если хочется какой-то там чистоты, то для сборки каждого пакета создается в чруте или контейнере минимальная система со сборочными зависимостями пакета и сборка каждого пакета производится в своем контейнере.

это как? тулчейн нужен-то лишь для сборки glibc.

теперь застрял на stage3, сборке в чруте. так как я собираюсь использовать пакетный менеджер CRUX'а, я собираю его в чруте (7. Entering Chroot and Building Additional Temporary Tools ). при сборке libarchive (зависимость PM'а) выдаёт ошибку

  CC       libarchive/archive_read_disk_posix.lo
In file included from /usr/include/linux/fs.h:19,
                 from libarchive/archive_read_disk_posix.c:56:
/usr/include/linux/mount.h:95:6: error: redeclaration of 'enum fsconfig_command'
   95 | enum fsconfig_command {
      |      ^~~~~~~~~~~~~~~~
In file included from libarchive/archive_read_disk_posix.c:38:
/usr/include/sys/mount.h:189:6: note: originally defined here
  189 | enum fsconfig_command
      |      ^~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:96:9: error: redeclaration of enumerator 'FSCONFIG_SET_FLAG'
   96 |         FSCONFIG_SET_FLAG       = 0,    /* Set parameter, supplying no value */
      |         ^~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:191:3: note: previous definition of 'FSCONFIG_SET_FLAG' with type 'enum fsconfig_command'
  191 |   FSCONFIG_SET_FLAG       = 0,    /* Set parameter, supplying no value */
      |   ^~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:97:9: error: redeclaration of enumerator 'FSCONFIG_SET_STRING'
   97 |         FSCONFIG_SET_STRING     = 1,    /* Set parameter, supplying a string value */
      |         ^~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:193:3: note: previous definition of 'FSCONFIG_SET_STRING' with type 'enum fsconfig_command'
  193 |   FSCONFIG_SET_STRING     = 1,    /* Set parameter, supplying a string value */
      |   ^~~~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:98:9: error: redeclaration of enumerator 'FSCONFIG_SET_BINARY'
   98 |         FSCONFIG_SET_BINARY     = 2,    /* Set parameter, supplying a binary blob value */
      |         ^~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:195:3: note: previous definition of 'FSCONFIG_SET_BINARY' with type 'enum fsconfig_command'
  195 |   FSCONFIG_SET_BINARY     = 2,    /* Set parameter, supplying a binary blob value */
      |   ^~~~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:99:9: error: redeclaration of enumerator 'FSCONFIG_SET_PATH'
   99 |         FSCONFIG_SET_PATH       = 3,    /* Set parameter, supplying an object by path */
      |         ^~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:197:3: note: previous definition of 'FSCONFIG_SET_PATH' with type 'enum fsconfig_command'
  197 |   FSCONFIG_SET_PATH       = 3,    /* Set parameter, supplying an object by path */
      |   ^~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:100:9: error: redeclaration of enumerator 'FSCONFIG_SET_PATH_EMPTY'
  100 |         FSCONFIG_SET_PATH_EMPTY = 4,    /* Set parameter, supplying an object by (empty) path */
      |         ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:199:3: note: previous definition of 'FSCONFIG_SET_PATH_EMPTY' with type 'enum fsconfig_command'
  199 |   FSCONFIG_SET_PATH_EMPTY = 4,    /* Set parameter, supplying an object by (empty) path */
      |   ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:101:9: error: redeclaration of enumerator 'FSCONFIG_SET_FD'
  101 |         FSCONFIG_SET_FD         = 5,    /* Set parameter, supplying an object by fd */
      |         ^~~~~~~~~~~~~~~
/usr/include/sys/mount.h:201:3: note: previous definition of 'FSCONFIG_SET_FD' with type 'enum fsconfig_command'
  201 |   FSCONFIG_SET_FD         = 5,    /* Set parameter, supplying an object by fd */
      |   ^~~~~~~~~~~~~~~
/usr/include/linux/mount.h:102:9: error: redeclaration of enumerator 'FSCONFIG_CMD_CREATE'
  102 |         FSCONFIG_CMD_CREATE     = 6,    /* Invoke superblock creation */
      |         ^~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:203:3: note: previous definition of 'FSCONFIG_CMD_CREATE' with type 'enum fsconfig_command'
  203 |   FSCONFIG_CMD_CREATE     = 6,    /* Invoke superblock creation */
      |   ^~~~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:103:9: error: redeclaration of enumerator 'FSCONFIG_CMD_RECONFIGURE'
  103 |         FSCONFIG_CMD_RECONFIGURE = 7,   /* Invoke superblock reconfiguration */
      |         ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:205:3: note: previous definition of 'FSCONFIG_CMD_RECONFIGURE' with type 'enum fsconfig_command'
  205 |   FSCONFIG_CMD_RECONFIGURE = 7,   /* Invoke superblock reconfiguration */
      |   ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:129:8: error: redefinition of 'struct mount_attr'
  129 | struct mount_attr {
      |        ^~~~~~~~~~
/usr/include/sys/mount.h:161:8: note: originally defined here
  161 | struct mount_attr
      |        ^~~~~~~~~~
make[1]: *** [Makefile:6721: libarchive/archive_read_disk_posix.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/build/libarchive-3.6.1'
make: *** [Makefile:3867: all] Error 2

и как вообще быть, если нужен будет PM CRUX'а, собирать в stage3 весь круксовый core? как разрулить зависимости, если в CRUX в core даны тока RDEPS и не даны BDEPS? может, Spoofing чего подскажет?

разобрался. надо было sed '/linux\/fs\.h/d' -i libarchive/archive_read_disk_posix.c перед configure. ответ был в книге