В этой главе мы откомпилируем и установим минимальную систему Linux. Эта система будет использоваться для построения конечной LFS-системы в следующей главе.
Сборка этой минимальной системы будет проходить в два этапа: сначала соберем независящие от основной системы средства (компилятор, ассемблер, компоновщик и библиотеки), а потом используем их для сборки других средств.
Файлы, компилируемые в этой главе, устанавливаются в каталог $LFS/tools для отделения их от файлов, устанавливаемых в следующей главе. Эти пакеты просто временные, мы не будем засорять ими нашу конечную LFS-систему.
Ключевым для понимания работы Linux-системы является знание того, какие пакеты используются, и для чего они нужны системе. Из этих соображений я даю краткие содержание и описание пакетов перед инструкциями по их установке. Для изучения краткого описания програм, входящих в пакет, обратитесь к Приложению A.
Инструкции по сборке подразумевают, что Вы используете интерпретатор командной строки bash. Также считается, что Вы уже распаковали исходные тексты и перешли с помощью команды cd в каталог с ними перед использованием команд.
Некоторые пакеты необходимо пропатчить перед компиляцией, но только когда это необходимо для решения тех или иных проблем. Часто патчи нужно применять в обеих главах (этой и следующей), но некоторые необходимы только в одной из глав. Поэтому не беспокойтесь, если не найдете инструкций по наложению некоторых скачанных патчей в этой главе.
В процессе установки многих пакетов Вы увидите предупреждения (warning) на экране. Это нормально, и Вы можете не обращать на них внимания. Все, что они говорят: внимание, есть неточность, но не ошибка, в коде C или C++. Это из-за того, что изменяются стандарты на язык C, а некоторые пакеты написаны в соответствии со старыми стандартами, а это не представляет проблемы для компилятора.
Если не сказано обратное, то Вы можете спокойно удалить каталоги с исходными текстами и файлами сборки пакетов в целях экономии дискового пространства.
Перед тем как продолжить, убедитесь, что переменная окружения LFS задана корректно выполнением команды:
echo $LFS
Вывод должен указывать на точку монтирования раздела LFS, я использую /mnt/lfs в качестве примера.
Этот раздел предназначен для объяснения некоторых логических и технических моментов рационального метода сборки. Ничего страшного, если Вы не поймете все, что написано здесь. Большая часть имеет значение при выполнении сборки конкретных пакетов. Вы можете вернуться сюда в любое время.
Основной целью главы 5 является подготовка окружения для входа через chroot для создания полноценной системы в главе 6. По ходу дела Вы соберете, используя основную систему, самодостаточные средства. Это будет сделано для обеспечения минимального риска и максимальной независимости одновременно. Другими словами, Вы соберете инструменты для сборки системы.
Важно: Перед дальнейшей работой Вы должны знать название Вашей платформы, которое также называется target triplet. В некоторых случаях target triplet может быть, к примеру таким: i686-pc-linux-gnu. Простейшим способом определения Вашего target triplet является запуск скрипта config.guess, который содержится во многих пакетах. Распакуйте архив с исходными текстами Binutils, запустите скрипт ./config.guess и запомните вывод.
Вам также необходимо знать имя динамичаского компоновщика для Вашей платформы, его также называют динимическим загрузчиком, не спутайте его со стандартным компоновщиком ld из Binutils. Динамический компоновщик является частью Glibc и служит для поиска и загрузки библиотек, в которых нуждается программа, подготовки программы к запуску и ее запуска. Как правило, динамический компоновщик называется ld-linux.so.2. На некоторых не очень распространенных платформах он называется ld.so.1, а на некоторых 64-ьитных платформах по другому. Вы можете определить имя динамического компоновщика для Вашей платформы, заглянув в каталог /lib основной системы. Безошибочным способом проверки случайной библиотеки на Вашей основной системе является запуск 'readelf -l <name of binary> | grep interpreter' и просмотр вывода команды.
Некоторые технические моменты, которые позволяют методам сборки из главы 5 работать:
Binutils устанавливаются первыми потому, что GCC и Glibc выполняют тестирование ассемблера и компоновщика во время запуска ./configure для определения того, какие настройки программного обеспечения выбраны или отключены. Это очень важно при первой реализации. Неверно сконфигурированные GCC и Glibc могут испортить все сборку средств и дистрибутив будет с ошибками. Благодаря тестированию Вы можете опрделить это своевременно.
Binutils устанавливают ассемблер и компоновщик в два места: /tools/bin и /tools/$TARGET_TRIPLET/bin. Точнее, средства в одном из каталогов являются жесткими ссылками на другие. Очень важным для компоновщика является порядок поиска библиотек. Точную информацию о нем можно получить от ld указав параметр --verbose. К примеру: 'ld --verbose | grep SEARCH' покажет текущие пути поиска и их порядок. Вы можете увидеть, какие файлы скомпонованы с помощью ld при компиляции программы-пустышки и используя переключатель --verbose. К примеру: 'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded' покажет, какие файлы были открыты удачно в процессе компоновки.
Следующим пакетом Вы установите GCC и в процессе работы ./configure увидите, например:
checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld
Это важно по причинам, описанным выше. И это также показывает, что скрипт конфигурации GCC не ищет в каталогах $PATH, какие средства использовать. Тем не менее, текущий процесс gcc, не использует эти пути поиска. Вы можете определить, какой стандартный компоновщик gcc используется, запуском: 'gcc -print-prog-name=ld'. Детальная информация получается от gcc добавлением параметра -v при компиляции. Например: 'gcc -v dummy.c' покажет полную информацию о препроцессоре, компиляторе и ассемблере, включая пути поиска gcc и другую информацию.
Следующим устанавливаемым пакетом будет Glibc. Наиболее важными зависимостями сборки Glibc являются компилятор, средства для двоичных файлов и заголовки ядра. Компилятор не представляет проблемы, Glibc всегда использует gcc из каталога $PATH. Двоичные средства и заголовки ядра могут привести к некоторым проблемам. Поэтому я не рискую и использую переключатели конфигурации для правильного выбора. После запуска ./configure Вы можете проверить содержимое файла config.make в каталоге glibc-build для получения информации. Вы будете использовать некотоые интересные параметры, такие как CC="gcc -B/tools/bin", которые определяют используемые средства, а также флаги -nostdinc и -isystem для контроля за путем поиска компилятора. Эти параметры показывают важный аспект пакета Glibc: он не обязательно полагается на средства по умолчанию.
После установки Glibc, Вы создадите некоторые установки для того, чтобы убедиться что пути для поиска содержат только каталоги в /tools. Вы установите откорректированный ld, в котором будет жестко указан путь поиска в /tools/lib. Затем Вы исправите spec-файл gcc для указания на Ваш новый динамический компоновщик в /tools/lib. Этот последний шаг жизненно важен для процесса. Как указано выше, путь к динамическому компоновщику будет жестко вшит в каждый исполняемый файл ELF. Вы можете убедиться в этов, запустив 'readelf -l <name of binary> | grep interpreter'. Благодаря исправлению spec-файла gcc, Вы убедитесь, что все программы из оставшейся части главы 5 будут использовать новый динамический компоновщик из /tools/lib.
Необходимость использования нового динамического компоновщика также является причиной, по которой Вы применяете Spec-патч на втором этапе сборки GCC. Опускание этого патча приведет к тому, что программы GCC будут использовать системный динамический компоновщик из каталога /lib основной системы, а это будет означать зависимость от основной системы.
В ходе второго шага сборки Binutils Вы будете использовать переключатель --with-lib-path для контроля путя поиска библиотек для ld. С этого момента все средства будут самодостаточными. Остальные пакеты из главы 5 будут собраны с новой Glibc из каталога /tools.
После входа в окружение chroot в главе 6, Вы первым делео установите Glibc по вышеописаным причинам. Теперь Glibc будет установлена в /usr, и Вы будете использовать средства по умолчанию для сборки остальных пакетов из главы 6 для LFS-системы.
Многие программы выполняют, помимо своей основной задачи, и многие другие операции. Это включает распределение памяти, поиск каталогов, чтение и запись файлов, манипуляции со строками, использование шаблонов, арифметические операции и многое другое. Вместо того, чтобы включать все это в программу, GNU-система поддерживает простые функции в библиотеках. Самой главной из них для любой Linux-системы является Glibc.
Есть два варианта использования библиотечных функций: статически и динамически. Когда программа скомпонована статически, код используемых функций включается в программу, и она становится более громоздкой. Когда же программа скомпонована динамически, в программу включаются только ссылка на динамический компоновщик, имя библиотеки и имя функции, в результате Вы получаете более маленький исполняемый файл. Есть еще третий путь: использование программного интерфейса для динамического компоновщика. Смотрите руководство по dlopen для более полной информации.
Динамическая компоновка является компоновкой по умолчанию в Linux и имеет три главных преимущества перед статической компоновкой. Первое: достаточно иметь только одну копию исполняемого кода библиотеки на жестком диске, в отличие от нескольких копий в каждом исполняемом файле в противном случае. Вы экономите место на диске. Второе, когда несколько программ используют одну и ту же библиотечную фунцию одновременно, только одна копия этой функции находится в памяти: Вы экономите оперативную память. Третье, если Вы обнаружили ошибку в функции, достаточно перекомпилировать одну библиотеку, в отличие от необходимости перекомпилировать все программы, использующие эту функцию, в противном случае.
Если динамическая компоновка настолько лучше, то почему ее не используют, а первые два пакета в этой главе компонуются статически? Есть тройственная причина для этого: историческая, образовательная и техническая. Историческая потому, что простейшая версия LFS статически компонует все программы из этой главы. Образовательная потому, что надо знать отличие между статической и динамической компоновкой. Техническая потому, что Вы получаете элемент независимости от основной системы, Ваши программы не должны от нее зависеть, они должны иметь возможность работать самостоятельно. Таким образом, если Вы хотите построить LFS-систему, необходимо отказаться от динамической компоновки первых двух пакетов.
Все программы, компилируемые в этой главе, устанавливаются в каталог $LFS/tools для обеспечения отсутствия проблемм с программами, собираемыми в следующей главе. Программы, компилируемые здесь, являются только временными средствами, и надо получить возможность легко избавится от них в дальнейшем.
Помимо этого надо отделить имя этого каталога от остальных. Для этого используется название "tools", при желаниии Вы можете использовать и другие названия, например, "tools_for_lfs".
Создайте каталог:
mkdir $LFS/tools
Теперь надо создать ссылку /tools на новый каталог в основной системе:
ln -s $LFS/tools /
Эта ссылка нужна потому, что все средства из этой главы будут собираться с префиксом /tools, и они же понадобятся в следующей главе (когда с помощью chroot войдете в новый раздел).
Замечание: Изучите эти команды внимательно. Это может показаться странным на первый взгляд. Но команда ln имеет множество различных вариантов синтаксиса, и Вы должны изучить man-страницу по ln прежде, чем сообщать о том, что Вы считаете, что обнаружили ошибку.
Если Вы зарегистрировались в ситеме как root, малейшая ошибка может иметь фатальные последствия для системы. Поэтому я рекомендую собирать пакеты из этой главы под непривилегированым пользователем. Вы, конечно, можете использовать имя текущего пользователя, но более простым шагом будет создание нового пользователя lfs и его повсеместное применение в процессе установки. Под правами root исполните следующие команды для добавления нового пользователя:
useradd -s /bin/bash -m lfs passwd lfs
Чтобы новый пользователь lfs получил полный доступ к каталогу $LFS/tools, измените ее владельца:
chown lfs $LFS/tools
Если Вы создали отдельный каталог для работы, смените также и его владельца на lfs:
chown lfs $LFS/sources
Теперь, войдите в систему как пользователь lfs. Это можно сделать через виртуальную консоль, через менеджер экрана или через команду:
su - lfs
Параметр "-" команды su запустит новый интерпретатор командной строки.
Когда Вы войдете в систему как lfs, введите следующие команды для настройки окружения:
cat > ~/.bash_profile << "EOF" set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX PATH=/tools/bin:$PATH export LFS LC_ALL PATH unset CC CXX CPP LD_LIBRARY_PATH LD_PRELOAD EOF source ~/.bash_profile
Команда set +h отключает функцию запоминания bash. Обычно это используется так: bash использует hash-таблицу для запоминания полного пути к исполняемым файлам для сокращения времени поиска и отсутствия необходимости запоминания путей этих файлов. Но Вы собираетесь использовать новые средства после установки. При отключении этой функции Ваши интерактивные команды (make, patch, sed, cp и другие) будут использовать наиболее новые из доступных версий программ в процессе сборки.
Установка маски для создания файлов пользователем в 022 позволит убедиться, что вновь созданные каталоги и файлы будут доступны для записи только их владельцу, а для чтения и выполнения любому желающему.
Переменная LFS указывает на точку монтирования, которую Вы выбрали для раздела LFS.
Переменная LC_ALL контролирует локализацию некоторых программ, делает вывод их сообщений зависимым от страны. Если Ваша система основана на Glibc старше версии 2.2.4, установка LC_ALL в что-то отличное от "POSIX" или "C" может создать проблемы при выходе и входе в среду chroot. Установкой LC_ALL в "POSIX" (или "C", что аналогично) Вы страхуетесь от ошибок при использовании chroot.
Вы добавляете /tools/bin к стандартной переменной PATH для того, чтобы на этапе сборки использовались средства, которые Вы уже собрали.
Переменные CC, CXX, CPP, LD_LIBRARY_PATH и LD_PRELOAD несут потенциальную опасность для средств из главы 5. Вы обнуляете их для того, чтобы было больше шансов собрать все корректно.
Теперь Вы можете приступить к сборке временных средств, используемых в следующих главах.
Ожидаемое время сборки: 1.0 SBU Ожидаемое место на диске: 194 MB
Binutils является коллекцией средств разработки программ, содержащих компоновщик, ассемблер и другие средства для работы с объектными файлами и архивами.
Устанавливаемые программы: addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings и strip.
Устанавливаемые библиотеки: libiberty.a, libbfd.[a,so] и libopcodes.[a,so]
Binutils зависит от: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.
Важно, чтобы Binutils был первым из пакетов, которые мы установим, потому, что Glibc и GCC проводят некоторые тесты на доступные компоновщик и ассемблер для определения доступных опций.
Замечание: Хотя Binutils является важным пакетом, мы не собираемся запускать тестирование на этом простом шаге. Во-первых, тестирование пока неуместно, а во-вторых, программы с этого этапа будут заново установлены на втором.
Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu). Binutils рекомендуется компилировать с настройками по умолчанию. Следовательно, если Вы задали переменные, такие как CFLAGS или CXXFLAGS, изменяющие уровень оптимизации по умолчанию, рекомендуется убрать их при сборке пакета binutils. Изменяя оптимизации для binutils, Вы действуете на свой страх и риск.
В документации по Binutils рекомендуется собирать Binutils вне каталога с исходными текстами, в отдельном каталоге, выделенном для сборки:
mkdir ../binutils-build cd ../binutils-build
Обратите внимание: Если Вы хотите вычислить переменную SBU, которая используется в этой книге, надо засечь время, которое понадобится на сборку этого пакета. Это очень просто сделать чем-то похожим на такую команду: time {./configure ... && ... && ... && make install;}.
Теперь подготовим Binutils к компиляции:
../binutils-2.14/configure --prefix=/tools --disable-nls
Описание используемых опций:
Вернемся к компиляции пакета:
make configure-host make LDFLAGS="-all-static"
Описание параметров сборки:
Теперь установим пакет:
make install
Теперь подготовим компоновщик к последующему встраиванию в Glibc:
make -C ld clean make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib
Описание параметров сборки:
Внимание! Не удаляйте сейчас каталоги для сборки и исходных текстов Binutils. Вам они еще будут нужны в этой главе далее в их теперешнем состоянии.
Ожидаемое время сборки: 4.4 SBU Ожидаемое место на диске: 300 MB
Пакет GCC pсодержит коллекцию компиляторов GNU, включая компиляторы C и C++.
Устанавливаемые программы: c++, cc (ссылка на gcc), cc1, cc1plus, collect2, cpp, g++, gcc, gccbug и gcov.
Устанавливаемые библиотеки: libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.[a,so] и libsupc++.a.
GCC зависит от Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed и Texinfo.
Распакуйте только архив GCC-core, Вам пока не нужен компилятор C++.
Замечание: Несмотря на то, что GCC является очень важным пакетом средств, сейчас тестирование не запускайте. Во-первых, тестирование сейчас не нужно, а во-вторых, программы с этого шага будут перезаписаны на следующем.
Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu). GCC рекомендуется компилировать с настройками по умолчанию. Следовательно, если Вы задали переменные такие как CFLAGS или CXXFLAGS, изменяющие уровень оптимизации по умолчанию, рекомендуется убрать их при сборке пакета GCC. Изменяя оптимизации для GCC, Вы действуете на свой страх и риск.
В документации на GCC рекомендуется собирать GCC вне каталога с исходными текстами в отдельном каталоге для сборки:
mkdir ../gcc-build cd ../gcc-build
Подготовьте GCC к компиляции:
../gcc-3.3.1/configure --prefix=/tools --with-local-prefix=/tools \ --disable-nls --enable-shared --enable-languages=c
Описание опций конфигурации:
Продолжите компиляцию пакета:
make BOOT_LDFLAGS="-static" bootstrap
Описание параметров сборки:
Теперь установите пакет:
make install
Под конец создайте ссылку /tools/bin/cc. Многие программы и скрипты используют cc вместо gcc для обеспечения переносимости программ на все Unix-системы. Не у всех установлен именно компилятор GNU C. Запуск cc позволяет администратору выбирать, какой компилятор C устанавливать в систему, так что создайте ссылку на него:
ln -sf gcc /tools/bin/cc
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 186 MB
Ядро Linux является основой любой Linux-системы. Это то, что делает Linux самой собой. Когда компьютер включается и загружает систему Linux, самым первым загружается ядро. Ядро инициализирует аппаратные компоненты: последовательные и параллельные порты, звуковые карты, сетевые карты, контролеры IDE, контролеры SCSI и много чего еще. Собственно, ядро делает доступным аппаратные элементы системы и позволяет запускаться программам.
Устанавливаемые файлы: ядро и заголовки ядра.
Linux зависит от Bash, Binutils, Coreutils, Findutils, GCC, Glibc, Grep, Gzip, Make, Modutils, Perl и Sed.
Некоторые пакеты нуждаются в ссылках на заголовки ядра, и Вы должны распаковать архив ядра, собрать и скопировать необходимые файлы туда, где их сможет найти gcc.
Подготовьтесь к установке заголовков:
make mrproper
Это гарантирует, что дерево с исходными текстами ядра будет абсолютно чистым. Команда разработчиков ядра рекомендует выполнять эту команду перед каждой компиляцией ядра. Вы не можете быть абсолютно уверены в чистоте дерева даже после распаковки.
Создайте файл include/linux/version.h:
make include/linux/version.h
Создайте платформно-зависимую ссылку include/asm:
make symlinks
Установите платформно-зависимые файлы заголовков:
mkdir /tools/include/asm cp include/asm/* /tools/include/asm cp -R include/asm-generic /tools/include
Установите кросс-платформенные файлы заголовков:
cp -R include/linux /tools/include
Некоторые из заголовков ядра используют файл заголовков autoconf.h. Поскольку Вы пока не сконфигурировали ядро, надо создать этот файл для того, чтобы компиляция следующих пакетов не закончилась ошибкой. Создайте пустой файл autoconf.h:
touch /tools/include/linux/autoconf.h
Ожидаемое время сборки: 11.8 SBU Ожидаемое место на диске: 800 MB
Glibc является библиотекой C (версия GNU), которая обеспечивает системные вызовы и основные функции, такие как open, malloc, printf и т.д. Библиотека C используется всеми динамически скомпонованными программами. Это один из важнейших компонентов системы.
Устанавливаемые программы: catchsegv, gencat, getconf, getent, glibcbug, iconv, iconvconfig, ldconfig, ldd, lddlibc4, locale, localedef, mtrace, nscd, nscd_nischeck, pcprofiledump, pt_chown, rpcgen, rpcinfo, sln, sprof, tzselect, xtrace, zdump и zic.
Устанавливаемые библиотеки: ld.so, libBrokenLocale.[a,so], libSegFault.so, libanl.[a,so], libbsd-compat.a, libc.[a,so], libc_nonshared.a, libcrypt.[a,so], libdl.[a,so], libg.a, libieee.a, libm.[a,so], libmcheck.a, libmemusage.so, libnsl.a, libnss_compat.so, libnss_dns.so, libnss_files.so, libnss_hesiod.so, libnss_nis.so, libnss_nisplus.so, libpcprofile.so, libpthread.[a,so], libresolv.[a,so], librpcsvc.a, librt.[a,so], libthread_db.so и libutil.[a,so].
Glibc зависит от Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed и Texinfo.
Перед началом установки Glibc, Вы должны перейти (с помощию команды cd, например) в каталог glibc-2.3.2 и распаковать архив Glibc-linuxthreads в этом каталоге, а не там, где Вы обычно распаковываете все исходные тексты.
Замечание: Я собираюсь запустить тестирование для Glibc в этой главе. Это тестирование тут является менее важным, чем тестирование Glibc в главе 6.
Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu). Glibc рекомендуется компилировать с настройками по умолчанию. Следовательно, если Вы задали такие переменные, как CFLAGS или CXXFLAGS, изменяющие уровень оптимизации по умолчанию, рекомендуется убрать их при сборке пакета Glibc. Изменяя оптимизации для glibc, Вы действуете на свой страх и риск.
Хотя это и безвредное сообщение, но при установке Glibc жалуется на отсутствие /tools/etc/ld.so.conf. Исправьте это с помощью команд:
mkdir /tools/etc touch /tools/etc/ld.so.conf
Также, Glibc имеет некоторые тонкие проблемы при компиляции с помощью GCC 3.3.1. Примените следующий патч для их исправления:
patch -Np1 -i ../glibc-2.3.2-sscanf-1.patch
Документация по Glibc рекомендует собирать Glibc вне каталога с исходными текстами, в отдельном каталоге для сборки:
mkdir ../glibc-build cd ../glibc-build
Далее, подготовьте Glibc к компиляции:
../glibc-2.3.2/configure --prefix=/tools --disable-profile --enable-add-ons \ --with-headers=/tools/include \ --with-binutils=/tools/bin --without-gd
Описание опций конфигурации:
На этом шаге Вы можете увидеть следующее предупреждение:
configure: WARNING: *** These auxiliary programs are missing or incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions.
Отсутствующая или несовместимая версия программы msgfmt безвредна, но может привести к определенным проблемам при тестировании.
Скомпилируйте пакет:
make
Запустите тестирование:
make check
Тестирование Glibc сильно зависит от некоторых функций основной системы, в частности, от ее ядра. Также, некоторые тесты в этой главе могут взаимодействовать с окружением Вашей системы. Само собой, Вы уже не должны получить таких проблем при запуске тестирования в главе 6. В общем, тестирование Glibc должно пройти удачно. Тем не менее, по причинам, перечисленным ниже, тестирование может закончиться и неудачно. Вот список наиболее вероятных причин этого:
В общем, не стоит беспокоится, если увидите, что тестирование Glibc не прошло. Glibc в главе 6 будет последним из устанавливаемых пакетов, и его тестирование будет более важным. Но имейте в виду. что в главе 6 некоторые тесты могут также не пройти: тест math, к примеру. Когда Вы получите сообщение о непрохождении теста, запомните его, а затем продолжите тестирование дальше. Это можно сделать, так как скрипт тестирования запоминает пройденые тесты для возможности его продолжения после выхода из-за ошибки. Вы можете использовать эту возможность "запуска-остановки" автоматически с помощью команды make -k check. Но если Вы так сделаете, проверьте протокол тестирования и посмотрите общее количество и причины проваленных тестов.
Теперь установите пакет:
make install
Разные страны и культуры имеют различные соглашения для коммуникаций. Эти соглашения состоят как из очень простых, таких как форматы даты и времени, так и из более сложных, таких как разговорный язык. "Интернационализация" программ GNU работает с помощью локалей (locales). Так что установите локали для Glibc:
make localedata/install-locales
Альтернативой запуску предыдущей команды является установка только определенных локалей, тех, которые Вам нужны. Это может быть достигнуто использованием команды localedef. Информацию об использовании этой команды можно получить из файла INSTALL в исходных текстах glibc-2.3.2. Тем не менее, список локалей может быть существенным для некоторых тестов, в частности, теста libstdc++ из GCC. Следующие команды, используемые вместо вышеописаной install-locales, установят минимальный набор локалей для успешного завершения тестирования:
mkdir -p /tools/lib/locale localedef -i de_DE -f ISO-8859-1 de_DE localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro localedef -i en_HK -f ISO-8859-1 en_HK localedef -i en_PH -f ISO-8859-1 en_PH localedef -i en_US -f ISO-8859-1 en_US localedef -i es_MX -f ISO-8859-1 es_MX localedef -i fr_FR -f ISO-8859-1 fr_FR localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro localedef -i it_IT -f ISO-8859-1 it_IT localedef -i ja_JP -f EUC-JP ja_JP
Теперь, когда временные библиотеки C были установлены, Вы хотите, чтобы все оставшиеся в этой главе пакеты компоновались с использованием уже установленных библиотек. Чтобы обеспечить это, Вы должны настроить spec-файл компилятора.
Для начала установите откорректированый компоновщик запуском следующей команды в каталоге binutils-build:
make -C ld install
Вы установили откорректированый компоновщик вместо того, который был установлен на первом шаге сборки Binutils. С этого момента все пакеты быдут собраны только с использованием библиотек из /tools/lib.
Замечание: Если Вы пропустили предупреждение о том, что не надо было удалять каталоги с исходными текстами и сборкой Binutils из первого шага или у Вас нет доступа к ним, не беспокойтесь, не все потеряно. Просто проигнорируйте вышеприведенную команду. В результате появится небольшой шанс, что программы будут скомпонованы с использованием библиотек основной системы. Это не очень хорошо, но тем не менее не является такой уж большой проблемой. Ситуация будет исправлена позже на втором шаге установки Binutils.
Теперь, когда установлен откорректированый компоновщик, Вы можете удалить каталоги с исходными текстами и сборкой Binutils.
Следующим Вашим действием будет исправление spec-файла GCC для задания расположения Вашего компоновщика. Просто выполните следующую команду:
SPECFILE=/tools/lib/gcc-lib/*/*/specs && sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \ $SPECFILE > tempspecfile && mv -f tempspecfile $SPECFILE && unset SPECFILE
Я рекомендую просто скопировать и вставить вышеуказанное вместо того, чтобы просто вводить. Или, при желании, Вы можете просто отредактировать spec-файл вручную: замените встречающиеся строки "/lib/ld-linux.so.2" на "/tools/lib/ld-linux.so.2".
Важно: Если Вы работаете на платформе, где имя динамического компоновщика отлично от ld-linux.so.2, Вы должны заменить ld-linux.so.2 на имя динамического компоновщика Вашей платформы в вышеуказанных командах. При необходимости вернитесь к разделу "Технические моменты".
Есть возможность, что некоторые включаемые файлы из основной системы имеются внутри каталогов для включаемых файлов GCC. Это могло произойти по причине того, что процесс "fixincludes" запускается как часть сборки GCC. Позже я расскажу об этом подробнее в этой главе. А пока запустите следующую команду, чтобы исключить эту возможность:
rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}
Внимание! На этом месте необходимо остановиться и убедиться, что основные функции (компиляция и компоновка) новых средств работают корректно. Для этого есть простой тест:
echo 'main(){}' > dummy.c gcc dummy.c readelf -l a.out | grep ': /tools'
Если все в порядке, то не будет ошибок, и на выводе Вы увидите:
[Requesting program interpreter: /tools/lib/ld-linux.so.2]
Если эта надпись вообще не появилась или появилась другая, то что-то сильно не так. Вам надо исследовать и повторить все пройденные шаги, чтобы найти, в чем проблема и устранить ее. Точки для возврата после этого места уже не будет. Как правило, что-то не так бывает с вышеописанной правкой spec-фала. Убедитесь, что /tools/lib содержит префикс Вашего динамического компоновщика. Само собой, если Вы работаете на платформе с названием динамического компоновщика, отличным от ld-linux.so.2, вывод будет несколько иным.
Если все прошло нормально, удалите тестовые файлы:
rm dummy.c a.out
Теперь Вы закончили установку самодостаточных средств, и они будут использованы для сборки оставшихся временных средств.
Ожидаемое время сборки: 0.9 SBU Ожидаемое место на диске: 23 MB
Пакет Tcl содержит язык Tool Command Language.
Устанавливаемые программы: tclsh (ссылка на tclsh8.4), tclsh8.4.
Устанавливаемые библиотеки: libtcl8.4.so.
Tcl зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make и Sed.
Этот и следующие два устанавливаемых пакета нужны для работы тестирования GCC и Binutils. Установка этих трех пакетов нужна только для этого, и если Вы не хотите тестировать устанавливаемые средства, то можно пропустить эти установки, но я рекомендую проверять работоспособность собираемых средств.
Подготовьте Tcl к компиляции:
cd unix ./configure --prefix=/tools
Соберите пакет:
make
Этот пакет поддерживает тесты для определения корректности сборки. Тем не менее, тестирование Tcl в этой главе может не завершиться успещно из-за зависимостей от основной системы, которые полностью не понятны. Таким образом, неудачное завершение тестирования здесь не будет сюрпризом и не является критичным. Если Вы решили протестировать Tcl, то запустите команду:
TZ=UTC make test
Описание параметров сборки:
Иногда, тестирование пакета не проходит. Вы можете проконсультироваться на LFS Wiki по адресу http://wiki.linuxfromscratch.org для проверки того, какие из ошибок нормальны. Это относится ко всем тестированиям в этой книге.
Установите полученный пакет:
make install
Важно: Не удаляйте каталог с исходными текстами tcl8.4.4 сейчас, так как следующие пакеты будут нуждаться во внутренних заголовках из этого каталога.
Создайте необходимую символическую ссылку:
ln -s tclsh8.4 /tools/bin/tclsh
Ожидаемое время установки: 0.1 SBU Ожидаемое мето на диске: 3.9 MB
Пакет Expect содержит программы, обеспечивающие программируемый диалог с другими интерактивными программами.
Устанавливаемые программы: expect.
Устанавливаемые библиотеки: libexpect5.39.a.
Expect зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed и Tcl.
Для начала примениие патч:
patch -Np1 -i ../expect-5.39.0-spawn.patch
Этот патч устранит неисправность в Expect, которая выдает неверный результат при тестировании GCC.
Теперь подготовьте Expect к компиляции:
./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no
Описание опций конфигурации:
Теперь откомпилируйте пакет:
make
Этот пакет поддерживает тестирование для проверки корректности сборки. Тем не менее, тестирование Expect здесь, в главе 5, известно своими ошибками из-за влияния основной системы. Таким образом, отрицательные результаты тестов не будут здесь сюрпризом и не являются критичными. Если Вы захотите запустить тестирование, воспользуйтесь следующей командой:
make test
Установите готовый пакет:
make SCRIPTS="" install
Описание параметров установки:
Теперь Вы можете удалить каталог с исходными текстами Tcl и Expect.
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 8.6 MB
Пакет DejaGnu содержит основы для тестирования других программ.
Устанавливаемые программы: runtest
Dejagnu зависит от: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.
Подготовим DejaGnu к компиляции:
./configure --prefix=/tools
Соберите и установите пакет:
make install
Ожидаемое время сборки: 11.0 SBU Ожидаемое место на диске: 274 MB
Средства, необходимые для тестирования GCC и Binutils, теперь установлены (Tcl, Expect и DejaGnu). Можно вернуться к пересборке GCC и Binutils, соединить их с новой Glibc и правильно их протестировать. Но есть одно замечание: тестирование сильно зависит от правильного функционирования терминалов PTY из основной системы. На данный момент, PTY реализованы с помощью файловой системы devpts. Вы можете быстро проверить правильность установки системы командой:
expect -c "spawn ls"
Если Вы получили ответ:
The system has no more ptys. Ask your system administrator to create more.
то Ваш основной дистрибутив не поддерживает операции PTY. В этом случае здесь не место запуску тестирования для GCC и Binutils, и Вы можете пропустить его. Вы можете проконсультироваться в LFS Wiki на http://wiki.linuxfromscratch.org для более подробной информации.
Распакуйте все три архива GCC (core, g++ и testsuite) в одном рабочем каталоге. Они распакуются в один общий подкаталог gcc-3.3.1.
Для начала исправьте одну проблему и создайте необходимую сборку:
patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch patch -Np1 -i ../gcc-3.3.1-specs-2.patch
Первый патч отключит скрипт GCC fixincludes. При нормальных обстоятельствах скрипт GCC fixincludes сканирует систему на предмет поиска файлов заголовков Glibc, нуждающихся в исправлении, исправляет их и переносит их в каталог подключаемых файлов для GCC. После чего, в главе 6, после установки новой Glibc, этот каталог будет найден, и в результате GCC найдет заголовки основной системы, а Вы не сможете корректно использовать Glibc в системе LFS.
Последний патч изменяет расположение по умолчанию для динамического компоновщика GCC (обычно ld-linux.so.2). Он также удаляет /usr/include из пути для поиска GCC. Пропатчивание spec-файла сейчас позволит убедиться, что Ваш новый динамический компоновщик будет использоваться собираемым GCC. То есть, Ваши окончательные и временные двоичные иодули будут скомпонованы уже с новой Glibc.
Важно: Эти патчи являются критичными для корректной сборки. Не забудьте применить их.
Создайте отдельный каталог для сборки и перейдите в него:
mkdir ../gcc-build cd ../gcc-build
Перед началом сборки GCC не забудьте дезактивировать все переменные окружения, в которых были изменены параметры для оптимизации.
Теперь подготовьте GCC к компиляции:
../gcc-3.3.1/configure --prefix=/tools --with-local-prefix=/tools \ --enable-clocale=gnu --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-languages=c,c++
Описание опций конфигурации:
Скомпилируйте пакет:
make
Здесь нет необходимости использовать цепь bootstrap, так как Вы компилируете этот GCC с помощью той же самой версии GCC, но установленой ранее.
Замечание: Запуск тестирования здесь не настолько важен, как в главе 6.
Протестируйте результаты:
make -k check
Флаг -k используется для того, чтобы тестирование не прекратилось после получения первого отрицательного результата, а проводились дальнейшие тесты. Тестирование GCC довольно исчерпывающее, и поэтому Вы практически гарантировано получите пару отрицательных результатов тестов. Для просмотра результатов тестирования выполните команду:
../gcc-3.3.1/contrib/test_summary | more
Вы можете сравнить Ваши результаты с результатами из списка рассылки для того, чтобы найти аналогичные Вашим. К примеру, посмотреть результаты тестирования GCC-3.3.1 на i686-pc-linux-gnu можно на http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.
Проверьте, чтобы в результатах были:
* 1 XPASS (unexpected pass) for g++ * 1 FAIL (unexpected failure) for g++ * 2 FAIL for gcc * 26 XPASS's for libstdc++
Неожиданным прохождением тест для g++ обязан использованию --enable-__cxa_atexit. Но не все платформы поддерживающие GCC поддерживают также и "__cxa_atexit" в своих библиотеках C, поэтому этот тест не всегда может пройти.
26 неожиданных успешных тестов libstdc++ обязаны использованию --enable-clocale=gnu, которая корректирует выбор на Glibc-системах версий 2.2.5 и выше. Поддержка основных локалей в библиотеке GNU C важнее, в противном случае выбирается "общая" модель (которая может быть применима в случаях использования Newlibc, Sun-libc или других libc). Тестирование libstdc++ в случае применения "основной" модели для тестов не всегда может пройти успешно.
Неожиданные отрицательные результаты также не могут быть проигнорированы. Разработчики GCC обычно знают о них, но пока не могут исправить. В общем, проверьте результаты, как было описано выше. Если все в порядке, то можно продолжать.
Наконец установите пакет:
make install
Замечание: В этом месте рекомендуется повторить простой тест, описанный ранее. Вернитесь к части "Интеграция Glibc" и повторите проверку. Если она не удалась, видимо, Вы забыли наложить вышеупомянутый патч GCC Specs.
Ожидаемое время сборки: 1.5 SBU Ожидаемое место на диске: 108 MB
Снова создадим отдельный каталог для сборки:
mkdir ../binutils-build cd ../binutils-build
Теперь подготовим Binutils к компиляции:
../binutils-2.14/configure --prefix=/tools --enable-shared \ --with-lib-path=/tools/lib
Описание опций конфигурации:
Перед началом сборки Binutils не забудьте сбросить значения переменных окружения с флагами оптимизации по умолчанию.
Теперь откомпилируем пакет:
make
Замечание: Здесь не обязательно запускать тестирование Binutils, так как это не настолько важно, как в главе 6.
Протестируем полученные результаты:
make check
К сожалению, нет простого пути увидеть результаты теста, как в предыдущем пакете GCC. Тем не менее, если тестирование не прошло, то это сразу будет видно. На выводе будет что-то наподобие:
make[1]: *** [check-binutils] Error 2
Теперь установим пакет:
make install
Теперь подготовим Binutils к переопределению средств в следующей главе:
make -C ld clean make -C ld LIB_PATH=/usr/lib:/lib
Внимание! Не удаляйте сейчас каталоги с исходными текстами и сборкой Binutils. Они будут нужны в следующей главе в их нынешнем виде.
Ожидаеморе время сборки: 0.2 SBU Ожидаемое место на диске: 17 MB
Gawk является реализацией awk, который используется для манипуляций с текстовыми файлами.
Устанавливаемые программы: awk (ссылка на gawk), gawk, gawk-3.1.3, grcat, igawk, pgawk, pgawk-3.1.3 и pwcat.
Gawk зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make и Sed.
Подготовьте Gawk к компиляции:
./configure --prefix=/tools
Откомпилируйте пакет:
make
Этот пакет поддерживает тестирование корректности сборуи. Вы можете запустить его командой:
make check
Теперь установите пакет:
make install
Ожидаемое время сборки: 0.9 SBU Ожидаемое место на диске: 69 MB
Пакет Coreutils содержит некоторые простые системные утилиты.
Устанавливаемые программы: basename, cat, chgrp, chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups, head, hostid, hostname, id, install, join, kill, link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mv, nice, nl, nohup, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink, rm, rmdir, seq, sha1sum, shred, sleep, sort, split, stat, stty, su, sum, sync, tac, tail, tee, test, touch, tr, true, tsort, tty, uname, unexpand, uniq, unlink, uptime, users, vdir, wc, who, whoami и yes.
Coreutils зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.
Подготовьте Coreutils к компиляции:
./configure --prefix=/tools
Скомпилируйте пакет:
make
Этот пакет поддерживает тестирование корректности сборки. Вы можете запустить его командой:
make RUN_EXPENSIVE_TESTS=yes check
Описание параметров make:
Теперь установите пакет:
make install
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 2.5 MB
Bzip2 является блочным файловым компрессором (block-sorting file compressor), который сжимает, как правило, лучше традиционного gzip.
Устанавливаемые программы: bunzip2 (ссылка на bzip2), bzcat (ссылка на bzip2), bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2, bzip2recover, bzless и bzmore.
Устанавливаемые библиотеки: libbz2.a, libbz2.so (link to libbz2.so.1.0), libbz2.so.1.0 (link to libbz2.so.1.0.2) и libbz2.so.1.0.2.
Bzip2 зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Make.
Пакет Bzip2 не содержит скрипта configure. Он компилируется и устанавливается одной командой:
make PREFIX=/tools install
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 2.6 MB
Пакет Gzip содержит программы для сжатия и распаковки файлов с использованием алгоритма сжатия LZ77.
Устанавливаемые программы: gunzip (ссылка на gzip), gzexe, gzip, uncompress (ссылка на gunzip), zcat (ссылка на gzip), zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore и znew.
Gzip зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make и Sed.
Подготовьте Gzip к установке:
./configure --prefix=/tools
Скомпилируйте пакет:
make
Теперь установите его:
make install
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 7.5 MB
Программы из этого пакета могут показать различия между двумя (или тремя) файлами или каталогами. Они обычно используются для создания различных патчей.
Устанавливаемые программы: cmp, diff, diff3 и sdiff.
Diffutils зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make и Sed.
Подготовьте Diffutils к компиляции:
./configure --prefix=/tools
Скомпилируйте пакет:
make
Теперь установите его:
make install
Ожидаемое время сборки: 0.2 SBU Ожидаемое место на диске: 7.6 MB
Пакет Findutils содержит программы для поиска файлов, в том числе на лету (путем рекурсивного поиска по каталогам и показывая только файлы, удовлетворяющие параметрам поиска) или поиск через базу данных.
Устанавливаемые программы: bigram, code, find, frcode, locate, updatedb и xargs.
Findutils зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make и Sed.
Подготовьте Findutils к компиляции:
./configure --prefix=/tools
Скомпилируйте пакет:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите запустить его, выполните следующую команду:
make check
Теперь установите пакет:
make install
Ожидаемое время сборки: 0.2 SBU Ожидаемое место на диске: 8.8 MB
Make автоматически определяет, какие части большой программы должны быть перекомпилированы и вызывает команды для их перекомпиляции.
Устанавливаемые программы: make.
Make зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep и Sed.
Подготовьте Make к компиляции:
./configure --prefix=/tools
Скомпилируйте программу:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите запустить его, выполните следующую команду:
make check
Теперь установим пакет и документацию к нему:
make install
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 5.8 MB
Grep является пролграммой, используемой для печати строк из файла, которые совпадают с заданым шаблоном.
Устанавливаемые программы: egrep (ссылка на grep), fgrep (ссылка на grep) и grep.
Grep зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Make, Sed и Texinfo.
Подготовьте Grep к компиляции:
./configure --prefix=/tools --disable-perl-regexp --with-included-regex
Описание параметров конфигурации:
Скомпилируйте программу:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите это использовать, выполните команду:
make check
Теперь установите пакет и документацию к нему:
make install
Ожидаемое время сборки: 0.2 SBU Ожидаемое место на диске: 5.2 MB
Sed является редактором потоков. Редактор потоков используется для выполнения простых преобразований текста во входном потоке (файл или стандартный ввод).
Устанавливаемые программы: sed.
Sed зависит от: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make и Texinfo.
Подготовьте Sed к компиляции:
./configure --prefix=/tools
Скомпилируйте программу:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите использовать это, то выполните команду:
make check
Теперь установите пакет и документацию:
make install
Ожидаемое время сборки: 7.2 SBU Ожидаемое место на диске: 55 MB
Пакет Gettext используется для интернационализации и локализации. Программы могут быть скомпилированы с поддержкой родного языка (Native Language Support, NLS) для получения возможности вывода сообщений на языке пользователя.
Устанавливаемые программы: autopoint, config.charset, config.rpath, gettext, gettextize, hostname, msgattrib, msgcat, msgcmp, msgcomm, msgconv, msgen, msgexec, msgfilter, msgfmt, msggrep, msginit, msgmerge, msgunfmt, msguniq, ngettext, project-id, team-address, trigger, urlget, user-email и xgettext.
Устанавливаемые библиотеки: libasprintf[a,so], libgettextlib[a,so], libgettextpo[a,so] и libgettextsrc[a,so].
Gettext зависит от Bash, Binutils, Bison, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make и Sed.
Подготовьте Gettext к компиляции:
./configure --prefix=/tools
Скомпилируйте пакет:
make
Этот пакет поддерживает тестирование корректности сборки. Тем не менее, тестирование Gettext в этой главе может не пройти успешно из-за зависимостей от основной системы, к примеру, если будет найден компилятор Java. Тестирование Gettext занимает много времени и не является критичным. Поэтому я не рекомендую запускать его здесь. Если же Вы все-таки захотите использовать его, выполните команду:
make check
Теперь установите пакет:
make install
Ожидаемое время сборки: 0.7 SBU Ожидаемое место на диске: 26 MB
Пакет Ncurses содержит библиотеки для расширения возможностей текстового интерфейса, включая панели и меню.
Устанавливаемые программы: captoinfo (ссылка на tic), clear, infocmp, infotocap (ссылка на tic), reset (ссылка на tset), tack, tic, toe, tput и tset.
Устанавливаемые библиотеки: libcurses.[a,so] (ссылка на libncurses.[a,so]), libform.[a,so], libmenu.[a,so], libncurses++.a, libncurses.[a,so] и libpanel.[a,so].
Ncurses зависит от Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make и Sed.
Сначала сделайте следующее:
patch -Np1 -i ../ncurses-5.3-etip-2.patch patch -Np1 -i ../ncurses-5.3-vsscanf.patch
Первый патч скорректирует файл заголовков etip.h, а второй исправит некоторые предупреждения компилятора при присутствии конкурирующих библиотек.
Теперь подготовьте Ncurses к компиляции:
./configure --prefix=/tools --with-shared --without-debug --without-ada \ --enable-overwrite
Описание параметров конфигурации:
Скомпилируйте программы и библиотеки:
make
Теперь установите пакет и документацию:
make install
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 1.9 MB
Программа patch модифицирует файлы в соответствии с файлом патча. Файл с патчем, как правило, список, сгенерированный программой diff, который содержит инструкции к тому, какие из оригинальных файлов нуждаются в модификации.
Устанавливаемые программы: patch.
Patch зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make и Sed.
Подготовьте Patch к компиляции:
CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools
Флаг препроцессора -D_GNU_SOURCE нужен только на платформах PowerPC. На других платформах Вы можете его пропустить.
Скомпилируйте программу:
make
Теперь установите пакет и документацию:
make install
Ожидаемое время сборки: 0.2 SBU Ожидаемое место на диске: 10 MB
Tar является архиватором, разработанным для сохранения и распаковки файлов в и из архивов, известных как tar-файлы.
Устанавливаемые программы: rmt и tar.
Tar зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make и Sed.
Подготовьте Tar к компиляции:
./configure --prefix=/tools
Скомпилируйте программу:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите это использовать. то выполните команду:
make check
Теперь установите пакет и документацию:
make install
Ожидаемое сремя сборки: 0.2 SBU Ожидаемое место на диске: 16 MB
Пакет Texinfo содержит программы, используемые для чтения, записи и конвертирования документов Info, которые содержат системную документацию.
Устанавливаемые программы: info, infokey, install-info, makeinfo, texi2dvi и texindex.
Texinfo зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses и Sed.
Подготовьте Texinfo к компиляции:
./configure --prefix=/tools
Скомпилируйте программы:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите использовать его, то выполните команду:
make check
Теперь установим пакет и документацию:
make install
Ожидаемое время сборки: 1.2 SBU Ожидаемое место на диске: 27 MB
Bash (Bourne-Again SHell) обычно используется как интерпретатор команд в Unix-системах. Программа bash считывает данные со стандартного ввода (клавиатуры, к примеру). Пользователь вводит что-либо, и программа определяет, что именно пользователь ввел, и что ей с этим делать, например, запустить другую программу.
Устанавливаемые программы: bash, sh (ссылка на bash) и bashbug.
Bash зависит от Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses и Sed.
Bash содержит несколько известных ошибок. Исправьте их, применив патч:
patch -Np1 -i ../bash-2.05b-2.patch
Теперь подготовьте Bash к компиляции:
./configure --prefix=/tools
Скомпилируйте программу:
make
Этот пакет поддерживает тестирование корректности сборки. Если Вы хотите использовать эту возможность, выполните команду:
make tests
Теперь установите пакет и документацию:
make install
Теперь создайте ссылку для программ, которые используют sh в качестве системной оболочки:
ln -s bash /tools/bin/sh
Ожидаемое время сборки: 0.1 SBU Ожидаемое место на диске: 8 MB
Пакет Util-linux содержит ряд разнообразных утилит. Некоторые из них используются весьма часто для монтирования, размонтирования, форматирования и управления драйверами дисков, открытия портов tty и вывода сообщений ядра.
Устанавливаемые программы: agetty, arch, blockdev, cal, cfdisk, chkdupexe, col, colcrt, colrm, column, ctrlaltdel, cytune, ddate, dmesg, elvtune, fdformat, fdisk, fsck.cramfs, fsck.minix, getopt, hexdump, hwclock, ipcrm, ipcs, isosize, kill, line, logger, look, losetup, mcookie, mkfs, mkfs.bfs, mkfs.cramfs, mkfs.minix, mkswap, more, mount, namei, parse.bash, parse.tcsh, pg, pivot_root, ramsize (ссылка на rdev), raw, rdev, readprofile, rename, renice, rev, rootflags (ссылка на rdev), script, setfdprm, setsid, setterm, sfdisk, swapoff (ссылка на swapon), swapon, test.bash, test.tcsh, tunelp, ul, umount, vidmode (ссылка на rdev), whereis и write.
Util-linux зависит от Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed и Zlib.
Util-linux не может использовать заголовки и библиотеки из каталога /tools. Это исправляется с помощью исправления скрипта конфигурации:
cp configure configure.backup sed "s@/usr/include@/tools/include@g" configure.backup > configure
Подготовьте Util-linux к компиляции:
./configure
Скомпилируйте поддержку некоторых шаблонов:
make -C lib
Поскольку Вам нужны только некоторые из утилит из этого пакета, соберите только их:
make -C mount mount umount make -C text-utils more
Теперь скопируйте эти файлы в каталог временных средств:
cp mount/{,u}mount text-utils/more /tools/bin<
Ожидаемое время сборки: 0.8 SBU Ожидаемое место на диске: 74 MB
Пакет Perl содержит язык perl (Practical Extraction and Report Language). Perl собрал некоторые лучшие свойства C, sed, awk и sh в одном мощном языке.
Устанавливаемые программы: a2p, c2ph, dprofpp, enc2xs, find2perl, h2ph, h2xs, libnetcfg, perl, perl5.8.0 (ссылка на perl), perlbug, perlcc, perldoc, perlivp, piconv, pl2pm, pod2html, pod2latex, pod2man, pod2text, pod2usage, podchecker, podselect, psed (ссылка на s2p), pstruct (ссылка на c2ph), s2p, splain и xsubpp.
Perl зависит от Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make и Sed.
Для начала примените патч для библиотеки C:
patch -Np1 -i ../perl-5.8.0-libc-3.patch
Убедитесь, что некоторые статические расширения будут собраны:
chmod u+w hints/linux.sh echo 'static_ext="IO re Fcntl"' >> hints/linux.sh
Теперь подготовьте Perl к компиляции:
./configure.gnu --prefix=/tools
Скомпилируйте только необходимые средства:
make perl utilities
Теперь скопируйте эти средства и их библиотеки в каталоги назначения:
mkdir -p /tools/lib/perl5/5.8.0 cp perl pod/pod2man /tools/bin cp -R lib/* /tools/lib/perl5/5.8.0
Описываемый здесь шаг не является обязательным. Если Ваш раздел LFS очень мал, Вы хотите просто попробовать или у Вас есть другие причины, то Вы можете выполнить инструкции этого раздела. Исполняемые файлы и библиотеки собираются с использованием ненужных символов отладки, это около 130 MB. Вы можете удалить эти символы командами:
strip --strip-unneeded /tools/{,s}bin/* strip --strip-debug /tools/lib/*
Первая команда пропустит около двадцати файлов, сообщив что они неподдерживаемого формата. Большая часть из них скрипты.
Ни в коем случае не используйте параметр --strip-unneeded для библиотек: они будут испорчены, и Вам придеться собирать их все заново вместе с Glibc.
Для освобождения еще пары мегабайт, можете убрать всю документацию:
rm -rf /tools/{,share/}{doc,info,man}
Вам понадобится около 850 MB свободного места на Вашей системе LFS для сборки и установки Glibc на следующем шаге. Если Вы сможете собрать и установить Glibc, то сможете собрать и установить все остальное.