документація<Попередній | зміст | Наступна>
5.2. Технічні примітки Toolchain
У цьому розділі пояснюються деякі обґрунтування та технічні деталі, що стоять за загальним методом побудови. Зовсім не обов’язково відразу зрозуміти все в цьому розділі. Більшість цієї інформації стане зрозумілішою після виконання фактичної збірки. До цього розділу можна звернутися в будь-який час під час процесу.
Загальна мета розділу 5 — створити тимчасову область, яка містить відомий набір інструментів, які можуть бути ізольовані від хост-системи. З допомогою chroot, команди в інших розділах будуть міститися в цьому середовищі, забезпечуючи чисту, безпроблемну збірку цільової системи LFS. Процес складання розроблено, щоб мінімізувати ризики для нових читачів і водночас забезпечити найбільшу освітню цінність.
примітки
Перш ніж продовжити, зверніть увагу на назву робочої платформи, яку часто називають цільовим триплетом. Простий спосіб визначити ім’я цільового триплета – запустити файл config.guess скрипт, який постачається з джерелом для багатьох пакетів. Розпакуйте джерела Binutils і запустіть скрипт: ./config.guess і зверніть увагу на вихід. Наприклад, для 32-розрядного процесора Intel вихід буде таким i686-pc-linux-gnu. У 64-розрядній системі це буде x86_64-pc-linux-gnu.
Також зверніть увагу на назву динамічного компонувальника платформи, який часто називають динамічним завантажувачем (не плутати зі стандартним компоновщиком ld що входить до складу Binutils). Динамічний компонувальник, наданий Glibc, знаходить і завантажує спільні бібліотеки, необхідні програмі, готує програму до запуску, а потім запускає її. Ім'я динамічного компонувальника для 32-розрядної машини Intel буде ld-linux.so.2 (ld-linux-x86-64.so.2 для 64-розрядних систем). Надійний спосіб визначити ім’я динамічного компонувальника – перевірити випадковий двійковий файл із хост-системи, виконавши: readelf -l | інтерпретатор grep і відзначаючи вихід. Авторитетне посилання на всі платформи знаходиться в shlib-версії файл у корені дерева джерел Glibc.
примітки
Перш ніж продовжити, зверніть увагу на назву робочої платформи, яку часто називають цільовим триплетом. Простий спосіб визначити ім’я цільового триплета – запустити файл config.guess скрипт, який постачається з джерелом для багатьох пакетів. Розпакуйте джерела Binutils і запустіть скрипт: ./config.guess і зверніть увагу на вихід. Наприклад, для 32-розрядного процесора Intel вихід буде таким i686-pc-linux-gnu. У 64-розрядній системі це буде x86_64-pc-linux-gnu.
Також зверніть увагу на назву динамічного компонувальника платформи, який часто називають динамічним завантажувачем (не плутати зі стандартним компоновщиком ld що входить до складу Binutils). Динамічний компонувальник, наданий Glibc, знаходить і завантажує спільні бібліотеки, необхідні програмі, готує програму до запуску, а потім запускає її. Ім'я динамічного компонувальника для 32-розрядної машини Intel буде ld-linux.so.2 (ld-linux-x86-64.so.2 для 64-розрядних систем). Надійний спосіб визначити ім’я динамічного компонувальника – перевірити випадковий двійковий файл із хост-системи, виконавши: readelf -l | інтерпретатор grep і відзначаючи вихід. Авторитетне посилання на всі платформи знаходиться в shlib-версії файл у корені дерева джерел Glibc.
Деякі ключові технічні моменти того, як працює метод збірки глави 5:
• Трохи відкоригуйте назву робочої платформи, змінивши триплет цільового поля "постачальник" за допомогою LFS_TGT змінної, гарантує, що перша збірка Binutils і GCC створить сумісний крос-лінкер і крос-компілятор. Замість того, щоб створювати двійкові файли для іншої архітектури, крос-компілятор і крос-компілятор створюватимуть двійкові файли, сумісні з поточним обладнанням.
• Тимчасові бібліотеки перехресно компілюються. Оскільки крос-компілятор за своєю природою не може покладатися ні на що зі своєї хост-системи, цей метод усуває потенційне забруднення цільової системи, зменшуючи ймовірність включення заголовків або бібліотек з хоста в нові інструменти. Перехресна компіляція також дає можливість створювати як 32-розрядні, так і 64-розрядні бібліотеки на 64-розрядному обладнанні.
• Ретельне маніпулювання джерелом GCC повідомляє компілятору, який цільовий динамічний компонувальник буде використаний.
Binutils встановлюється першим, тому що конфігурувати Запуски як GCC, так і Glibc виконують різні тести функцій на асемблері та компоновщику, щоб визначити, які функції програмного забезпечення потрібно ввімкнути або вимкнути. Це важливіше, ніж можна було б усвідомити. Неправильно налаштований GCC або Glibc може призвести до непомітно зламаної ланцюга інструментів, де вплив такої поломки може не проявитися до кінця збірки всього дистрибутива. Збій набору тестів зазвичай висвітлює цю помилку до того, як буде виконано занадто багато додаткової роботи.
Binutils встановлює асемблер і компонувальник у двох місцях, /tools/bin та /tools/$LFS_TGT/bin. Інструменти в одному місці жорстко пов’язані з іншим. Важливим аспектом компонувальника є його порядок пошуку в бібліотеці. Детальну інформацію можна отримати з ld передавши його -багатослівний прапор. Наприклад, an ld --дослівний | grep ПОШУК ілюструє поточні шляхи пошуку та їх порядок. Він показує, які файли пов’язані ld шляхом компіляції фіктивної програми та передачі -багатослівний переключитися на лінкер. Наприклад, gcc dummy.c -Wl,--verbose 2>&1
| grep succeeded покаже всі файли, успішно відкриті під час з’єднання.
Наступний встановлений пакет - це GCC. Приклад того, що можна побачити під час його пробігу конфігурувати це:
перевіряємо, який ассемблер використовувати... /tools/i686-lfs-linux-gnu/bin/як перевіряємо, який компонувальник використовувати... /tools/i686-lfs-linux-gnu/bin/ld
перевіряємо, який ассемблер використовувати... /tools/i686-lfs-linux-gnu/bin/як перевіряємо, який компонувальник використовувати... /tools/i686-lfs-linux-gnu/bin/ld
Це важливо з причин, зазначених вище. Це також демонструє, що сценарій налаштування GCC не здійснює пошук у каталогах PATH, щоб знайти інструменти для використання. Однак під час фактичної експлуатації с ПКУ не обов'язково використовуються ті самі шляхи пошуку. Щоб дізнатися, який стандартний лінкер ПКУ буде використовувати, запустити: gcc -print-prog-name=ld.
Детальну інформацію можна отримати з ПКУ передавши його -v параметр командного рядка під час компіляції фіктивної програми. Наприклад, gcc -v dummy.c покаже детальну інформацію про етапи препроцесора, компіляції та складання, в т.ч ПКУ' включає шляхи пошуку та їх порядок.
Далі встановлюються очищені заголовки API Linux. Вони дозволяють стандартній бібліотеці C (Glibc) взаємодіяти з функціями, які надає ядро Linux.
Наступний встановлений пакет – Glibc. Найважливішими міркуваннями для створення Glibc є компілятор, двійкові інструменти та заголовки ядра. Компілятор, як правило, не є проблемою, оскільки Glibc завжди використовуватиме компілятор, що стосується --господар параметр, переданий до його скрипту конфігурації; наприклад, у нашому випадку компілятор буде i686-lfs-linux-gnu-gcc. Бінарні інструменти та заголовки ядра можуть бути дещо складнішими. Тому не ризикуйте і використовуйте доступні перемикачі конфігурації, щоб забезпечити правильний вибір. Після пробігу конфігурувати, перевірте вміст config.make файл у файлі glibc-збірка каталог для всіх важливих деталей. Зверніть увагу на використання CC="i686-lfs-gnu-gcc" щоб контролювати, які двійкові інструменти використовуються та використання -ностдинк та -ісистема прапори для керування шляхом пошуку включення компілятора. Ці елементи підкреслюють важливий аспект пакету Glibc — він дуже самодостатній з точки зору механізму збирання і, як правило, не покладається на налаштування за замовчуванням у наборі інструментів.
Під час другого проходу Binutils ми можемо використовувати --with-lib-path налаштувати перемикач на керування ldШлях пошуку бібліотеки.
Для другого проходу GCC його джерела також повинні бути змінені, щоб вказати GCC використовувати новий динамічний компонувальник. Якщо цього не зробити, самі програми GCC матимуть ім’я динамічного компонувальника з хост-системи / lib каталог, вбудований у них, що порушить мету піти від хоста. Починаючи з цього моменту, основний ланцюжок інструментів є автономним і розташовується самостійно. Всі інші пакети розділу 5 побудовані на основі нового Glibc /інструменти.
Після входу до середовища chroot у Розділі 6, першим великим пакетом, який буде встановлено, є Glibc, через його самодостатню природу, згадану вище. Після встановлення цього Glibc / usr, ми виконаємо швидку зміну налаштувань ланцюжка інструментів за замовчуванням, а потім приступимо до створення решти цільової системи LFS.