Начиная очередную часть Самостроя, я должен извиниться перед читателями за некоторую скомканность изложения. Дело в том, что заметки эти были начаты до появления русского перевода LFS Book. И я собственно хотел в них совместить изложение рекомендаций Герарда с собственными впечатлениями от этого увлекательного процесса. Однако неожиданно поймал себя на мысли, что чем к более конкретным вещам я перехожу, тем больше скатываюсь на пересказ LFS Book. Что теперь не интересно даже тем, кто не очень хорошо владеет английским. Поэтому по возможности именно конкретные детали я буду опускать. Если что покажется неясным - обращайтесь к первоисточнику, информация в нем практически исчерпывающая. Хотя и касается лишь одного из возможных путей самостроя.
Определяющий этап самостроя - сборка главной системной библиотеки glibc. Однако прежде нам предстоит еще одно чрезвычайно ответственное дело - смена корневого каталога на /mount_point/basix, осуществляемая командой chroot. Выполнив ее, мы остаемся наедине с нашими статически собранными программами, и на помощь материнской LiveCD-системы рассчитывать уже не сможем. А потому нам следует озаботится созданием соответствуюшего окружения в новой среде обитания.
В этом окружении должны существовать: пути к исполнимым файлам относительно нового корня (то есть переменная PATH), и домашнему каталогу суперпользователя (переменная HOME), указание на тип терминала (переменная TERM), желательный вид приглашения командной строки (переменная PS1). Ну и о самой командной оболочке забывать не следует (ею на время будет /static/bin/bash - в отсчете от нового корня). Да и освободиться от прежнего окружения не помешает - дабы не путать новую шерсть со старой (это делается командой /static/bin/env -i - ясно, что она должна предществовать установке новых переменных). В итоге полная команда по смене корня приобретет вид вроде следующего:
$ chroot /mount_point/basix/static/bin/env -i > HOME=/root TERM=$TERM PS1='u:w$ ' > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/static/bin > /static/bin/bash --login
Сборка собственной системы дает практически неограниченные возможности по ее оптимизации. Правда, Герард Бикманс делать этого не рекомендует во избежание проблем. Однако буде такое желание все же возникнет - флаги оптимизации для компилятора gcc можно также определить в качестве переменных при смене корня, дабы потом каждый раз не вводить их вручную. Мой опыт показывает, что оптимизация под процессор (собиралось на Pentium 4) проходит безболезненно почти во всех случаях, немало способствуя итоговому быстродействию. Я использовал следующие значения флагов оптимизации:
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CXXFLAGS="$CFLAGS"
При желании прибегнуть к более жестким флагам оптимизации настоятельно рекомендуется ознакомиться с документацией по gcc соответствующей версии (для текущей на данный момент - 3.2.2, - ее можно найти здесь).
Итак, вводим команду chroot со всеми ее атрибутами и ждем Enter. Все, мосты сожжены: на время окружающий мир за пределами каталога basix для нас как бы перестал существовать. Правда, выход в него возможен черех другие виртуальные консоли - благо lonix поддерживает их аж шесть штук. Но, во избежание путаницы, на это лучше не полагаться. Да и необходимости в том не возникнет - если, конечно, все предществующие шаги были сделаны правильно.
Еще одно необходимое подгтовительное действие - монтирование файловой системы proc как разделяемой в соответствующий каталог будущей корневой файловой системы:
$ mount proc /proc -t proc
Кроме того, вспоминаем, что не зря создавался нами каталог /mount_point/basix/tmp - очень не вредно было бы подмонтировать в него файловую систему tmpfs, если таковая поддерживается дром материнской системы, это сдорово увеличит скорость компиляции (для небольших пакетов - в разы):
# mount tmpfs /mnt/tmpfs -t tmpfs
Теперь Герард рекомендует создать несколько символических ссылок - /etc/mtab -> /proc/mounts, /bin/bash -> /static/bin/bash, /bin/sh -> /static/bin/bash. Не вижу причин не последовать его совету. Напомню только, что здесь и далее отсчет корня идет от того каталога, в который мы переместились командой chroot.
Вслед за этим создаются файлы /etc/passwd и /etc/group - командой echo или в текстовом редакторе (не зря же мы его также собрали статически. В первый заносится пока единственный аккаунт - для администратора (root), с символом x вместо пароля (он пока ни к чему). А состав групп - более или менее произвольный. Тот список групп, который дает Герард, используется его сценарием MAKEDEV, чтобы не ломать голову, сделаем, как приказано. При желании же проявить самодеятельность нужно помнить, что в списке групп обязательно должна присуствтвовать группа tty - иначе в дальнейшем не установятся некоторые пакеты (в частности, util-linux).
Ну и собственно создание файлов устройств в каталоге /dev. Правда, мы же планируем использовать файловую систему devfs, которая создает все необходимые устройства автоматически - однако без файлов устройств не обойтись на стадии сборки программ.
Теперь - внимание, последний из подготовительных перед сборкой glibc шагов. Распаковываем (непосредственно в каталоге /usr/src) архив выбранной нами версии ядра системы, получая каталог вида /usr/src/linux-2.4.XX, делаем на него символическую ссылку /usr/src/linux -> /usr/src/linux-2.4.XX и, при желании использовать файловую систему XFS, накладываем необходимый патч:
bzip2 -dc $XFS-PATCH | patch -p1
Предварительно следует перейти в каталог /usr/src/linux - XFS-патч один из тех, которые накладываются внутри дерева исходников ядра.
Теперь т.н. заголовочные файлы ядра (header-файлы) следует скопировать туда, где они будут искаться при компиляции glibc (да и других пакетов тоже). Делать это следует очень внимательно, поэтому я не буду приводить соответствующих команд во избежание опечаток - лучше просто обратиться к труду Герарда. Где заодно можно прочитать обоснование того, почему header'ы следует именно копировать, а не устанавливать на них символические ссылки.
Теперь можно заняться собственно glibc. Распаковываем архив (например, в каталог /usr/src/tmp2), переходим в новообразованный каталог glibc-2.2.X и распаковываем в нем glibc-linuxthreads. А теперь потребуется внести некоторые изменения в исходники. У Герарда для этого предназначен специальный патч, однако он, естественно, привязан к конкретной версии glibc, мы же собраем ее произвольную (наиболее свежую на данный момент) версию. Так что придется вооружиться текстовым редактором (именно поэтому я настаивал на его включении в набор статически собранных пакетов).
Необходимость модификации исходников обусловлена следующим. Во-первых, в нашей недоношенной chroot-системе пакета glibc еще нет - и потому определение идентификатора пользователя по его имени (login'у) невозможно, а в исходниках glibc как аргумент команды chown фигурирует один пользователь (догадайтесь, како? - правильно, root). Так что все упонминания root'а следует заменить на его ID - то есть на 0.
Далее, при установке glibc используется Perl, если таковой доступен, и сслыки на его местонахождение даны в виде переменной $PERL. Однако в нашем случае Perl именно недоступен, поэтому переменную следует заменить на абсолютный путь - /usr/bin/perl, в результате он при конфигурировании просто игнорируется.
Итак, ищем, где же имеют место быть скараментальные символьные последовательности:
$ grep -R root *; $ grep -R $PERL *
Наперед скажу, что в той версии glibc, которая собиралась мной (2.3.1), да и в более ранних, слово root мы найдем в файле login/Makefile, а переменную $PERL - в файле malloc/Makefile (команды даются в предположении, что мы находимся в каталоге glibc-2.3.X). Так что открываем их в текстовом редакторе и зменяем соответствующие вхождения, как сказано выше.
Все остальное выполняем в точном соответствие с заветами Герарда. Правда, он советует отключить флаги оптимизации, если таковые были ранее определены как переменные окружения. Однако, на мой взшляд, это следует делать только в том случае, если сборка glibc закончилась ошибкой. Я уже говорил, что при тех флагах, которые были приведены в начале этого раздела, я собирал glibc неоднократно - и с неизбежно превосходным результатом. Надеюсь, что и у вас все окончится благополучно. Но если нет - вспомнить об отключении флагов никогда не поздно.
Продолжение следует