Собрать современный ARM тулчейн в Linux
Тут многие говорят, что тулчейн собрать сложно, и надо пользоваться готовыми.
Но мне тут понадобился C++11 (потестить с МК компил-тайм оптимизацию и виртуальные функции), и я решил собрать тулчейн.
binutils — 2.24, GCC — 4.8.2, Newlib — 2.1.0, gdb — 7.6.2
Download:
GNU toolchain:
Важный момент! Сборка должна вестись не в папке с исходниками.
Перед сборкой сделаем парочку общих определений, для того, чтобы если кому зажочется что-то поправить — он мог бы
Если в MY_DESTDIR записать «/», то тулчейн будет установлен в систему, иначе он будет ставится в отдельную папку, откуда стоит собирать пакет и ставить через пакетный менеджер. У меня Slackware, мои шаги по созданию пакетов вам не нужны.
Собираем binutils
Ставим его, как это принято у вас в дистрибутиве, или идём дальще, если MY_DESTDIR == «/»
Собираем gcc только для C.
Не забываем собрать пакет и поставить собранный пакет в систему.
Собираем newlib.
С newlib красношапачники накосячили в системе сборки, и без патча, исправляющего пути, он не соберётся. У всех бывают ошибки! Я бы мог приложить патч к топику и записать команду, но вместо этого я словами всё объясню
В файле newlib-2.1.0/libgloss/arm/cpu-init/Makefile.in
надо в
добавить после «objtype = @objtype@» «host_makefile_frag = $(srcdir)/../../config/default.mh» чтобы получилось
после чего всё собирётся
Не забываем собрать пакет и поставить собранный пакет в систему.
Собираем финальный gcc.
Не забываем собрать пакет и поставить собранный пакет в систему.
Собираем gdb.
Не забываем собрать пакет и поставить собранный пакет в систему.
Источник
1.1.8. GCC ToolChain¶
The Processor SDK Linux package contains an ARM-based toolchain for Cortex A devices. The ARM toolchain also enables hardware floating point (hardfp) support. Older toolchains including arm-arago-linux-gnueabi- uses software floating point (softfp). This results in software built using a hardfp toolchain being incompatible with software built with a softfp toolchain.
The Processor SDK Linux package uses an ARM-based tool chain. Other than using a newer version of GCC, the ARM tool chain also supports hard floating point, also known as Hard-FP. Hard-FP uses the FPU on the ARM instead of simulating it. Older tool chains including the Arago tool chain uses soft floating point (Soft-FP). Binaries built using a soft-fp tool chain are not compatible with binaries built using a hard-fp. Therefore, you must rebuild all binaries to use either hard-fp and soft-fp since you can’t mix and match. By default, all binaries included in the Processor SDK Linux package will be built for hard-fp.
The name of the toolchain binaries have also been updated from older versions of the SDK. Previous versions may have used a prefix of “arm-arago-linux-gnueabi-”. Current SDK ARMv7 toolchains use a prefix of “arm-linux-gnueabihf-” For example, the new toolchain’s gcc compiler is named arm-linux-gnueabihf-gcc.
Here is the structure of the Linux-devkit directory within the SDK.
| Element | Location |
| Toolchain Location | linux-devkit/sysroots/x86_64-arago-linux/usr/bin |
| Cross Compile Libraries Location | linux-devkit/sysroots/ -vfp-neon-linux-gnueabi/usr/lib |
| Headers for Cross Compiled Libraries Location | linux-devkit/sysroots/ -vfp-neon-linux-gnueabi/usr/include |
Location in SDK
The toolchain is located in the Linux SDK in the /linux-devkit directory. The following sections will cover the key components of the toolchain.
The cross-compilers and tools such as qmake2 can be found the the /linux-devkit/sysroots/x86_64-arago-linux/usr/bin directory. Adding this directory to your PATH will allow using these tools. For example:
host# export PATH=” /linux-devkit/sysroots/x86_64-arago-linux/usr/bin:$PATH”
Additional tools are also located here such as the qmake2, rcc, uic tools used by Qt. In addition there is a qt.conf file that can be used by tools such as Qt creator to use the pre-built libraries found in the Linux SDK.
The cross-compile tools are prefixed with a unique target triplet which indicates the architecture and OS of the output executable code. For example, the prefix arm-linux-gnueabihf- indicates the ARMv7 achitecture running the Linux OS, and thus the corresponding GCC cross compiler is called arm-linux-gnueabihf-gcc.
Reference the table below for all toolchain prefixes and their corresponding architectures found in Processor SDK.
| Toolchain Prefix | Architecture | Processor SDK Device |
| arm-oe-linux-gnueabi- | ARMv5 | omapl138-lcdk |
| arm-linux-gnueabihf- | ARMv7 | am335x-evm, am437x-evm, am57xx-evm, k2e-evm, k2g-evm, k2hk-evm, k2l-evm |
| aarch64-linux-gnu- | ARMv8 | am65xx-evm |
In an effort to be succient, the specific toolchain prefix will be replaced with $
The toolchain within the Linux SDK contains more than just the cross-compiler, it also contains pre-built libraries that can be used in your applications without requiring you to cross-compile them yourself. These libraries include packages from alsa to zlib. The libraries are located in the /linux-devkit/sysroots/ -vfp-neon-linux-gnueabi/ directory. For a list of the libraries you can refer to the software manifest found in the /docs directory or look at the list of libraries available in the /linux-devkit/sysroots/ -vfp-neon-linux-gnueabi/usr/lib directory. You will also find the header files corresponding to these libraries in the /linux-devkit/sysroots/ -vfp-neon-linux-gnueabi/usr/include directory. Usage of these libraries will be covered in more detail in the next sections, but as an example if your application wants access to the alsa asound library then you can now do the following command (assuming you have added the cross compiler to your PATH):
host# $
When cross-compiling packages that use configuration tools and autotools there are many settings that are required to make sure that the proper cross-compile libraries are used. The environment-setup script located in the /linux-devkit directory handles this for you. This script exports variables to perform actions such as:
- Adding the toolchain to the PATH
- Setting up CPATH
- Setting up PKG_CONFIG_* paths
- Setting standard variable such as CC, CPP, AR to the cross-compile values
To use the environment-setup script you only need to source it. This is as simple as:
host# source linux-devkit/environment-setup |
To know if the environment setup script has been sourced in your current shell the shell prompt will be changed to contain the [linux-devkit]: prefix in the command prompt.
The Usage section below will cover some cases where using the environment-setup script is useful.
When Compiling the Linux Kernel
Because environment-setup changes standard variables such as CC you should not use this script when compiler projects that build host-side as well as target-side tools. A prime example of this is the Linux kernel, which builds some host side tools to help during the kernel build. If the environment-setup script has been sourced then the CC value will specify the cross-compiler for the host-side tool build. This means that the tools compiled and used during the kernel build will be compiled for the ARM platform while the kernel build tries to run these tools on an Intel platform. This will cause the tools to fail to run and the kernel to fail to compile.
The following sections give some examples of how to use the included toolchain to compile simple applications such as HelloWorld to more complex examples such as configuring and compiler GStreamer plugins.
In the simplest case the cross-compiler can be used to compile simple applications that just need access to standard libraries. The two examples below cover an application that uses only the standard libgcc libraries and another example that uses the pthreads threading library.
Simple applications like HelloWorld can be compiled using just a call to the cross-compiler since the cross-compiler can find the libraries it was built with without any issues. The following steps will show how to make a simple helloworld application and cross-compile that application.
Create a helloworld.c file |
Cross-compile the helloworld.c file using the cross-compile toolchain. In this example we will invoke the toolchain without it having been added to our PATH.
host# /linux-devkit/sysroots/x86_64-arago-linux/usr/bin/$
After the above steps are run you should now have a helloworld executable in your directory that has been compiled for the ARM. A simple way to check this is to run the following command:
host# file helloworld
This should yield output like:
“helloworld: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, not stripped”
The ARM entry above was made bold for emphasis.
In many cases your simple application probably wants to use additional libraries than the standard libgcc and glibc libraries. In this case you will need to include the header files for those libraries as well as add the library to the compile line. In this example we will look at how to build a simple threading application and use the pthread library. This example was derived from the example code at **http://www.amparo.net/ce155/thread-ex.html**
Create a file thread-ex.c with the following contents
Cross-compile the thread-ex.c file using the cross-compile toolchain. In this example we will first add the toolchain to our PATH. This only needs to be done once. We will also add the pthread library to the compile line so that we will link with the library file that provides the pthread_* functions.
export PATH=” /linux-devkit/sysroots/x86_64-arago-linux/usr/bin/:$PATH”
$
The -lpthread entry above was made italics for emphasis.
The last case to cover is one where the environment-setup script is useful. In this case we will download the gst-plugins-bad package and configure and build it using the environment-setup script to configure the system for the autotools to properly detect the libraries available as pre-built libraries.
IMPORTANT In order to build the gst-plugins-bad package you will need libglib2.0-dev installed on your system. You can install this using sudo apt-get install libglib2.0-dev
Extract the plugins tarball tar zxf gst-plugins-bad-0.10.11.tar.gz
Change directory into the extracted sources cd gst-plugins-bad-0.10.11
Source the /linux-devkit/environment-setup script to prepare to configure and build the plugins. source /linux-devkit/environment-setup
Now configure the package. We need to define the host setting to tell the configuration utility what our host system is, and we will also disable some plugins that are known to be bad. ./configure –host=i686 –disable-deinterlace2 –disable-x264
When the configuration is done the last sections will show which plugins will be build based on the libraries available. This is the key point behind what the environment-setup script provides. By setting up the PKG_CONFIG_* paths and other variables the configure script was able to check for required libraries being available to know which plugins to enable. Now that the sources have been configured you can compile them with a simple make command. make
Источник
GCC Toolchain
Компиляторы — одна из самых сложных и интересных областей программирования. К счастью, у пользователей Linux есть отличная возможность изучать ее не только в теории, но и на практике. В любом дистрибутиве Linux можно найти GCC (GNU Compiler Collection) — набор компиляторов промышленного качества для нескольких популярных языков программирования, разработанный в рамках проекта GNU. Разумеется, исходный код GCC открыт и доступен для изучения всем желающим. Однако первые проблемы подстерегают новичков задолго до погружения в премудрости синтаксического анализа и генерации кода. Просто собрать GCC — задача не из легких.
Что такое тулчейн
Казалось бы, сборка проектов — стандартная и давно отработанная процедура. А тем, кто заинтересовался устройством GCC, рассказывать про знаменитую триаду ./configure && make && make install просто смешно. Даже богатый набор конфигурационных ключей и зависимости от вспомогательных библиотек обычно не сильно усложняют сборку. В сухой теории так оно и есть, но древо жизни GCC не просто зеленеет, а пышно цветет и колосится.
Дело в том, что GCC может нормально работать только в составе так называемого тулчейна [англ. toolchain — цепочка инструментов]. Этот англицизм, уже укоренившийся в русскоязычном профессиональном сообществе, подразумевает каскадно соединенный набор инструментов, решающий общую задачу — преобразование программы, написанной на языке программирования высокого уровня, в исполняемый файл. GCC — лишь одно из звеньев этой цепочки, которому, при всей его важности, необходимо кооперироваться с другими. В этом источник большинства проблем сборки тулчейнов. Как их решить, будет показано ниже, а сейчас кратко перечислим основные компоненты тулчейна, для простоты пока опуская некоторые вспомогательные библиотеки. » GCC — набор компиляторов с языков высокого уровня (С, C++, Ada, Fortran) в ассемблер.
- binutils — инструменты для манипуляций с объектными файлами и компиляции ассемблерного кода в машинный.
- libc — стандартная библиотека языка С.
- Заголовочные файлы ядра Linux.
- Набор отладочных инструментов (отладчик GDB; библиотеки для поиска утечек памяти duma, dmalloc; утилиты-трассировщики strace и ltrace). Строго говоря, это необязательные компоненты, однако в реальных проектах они могут оказаться очень полезны.
Типы тулчейнов
GCC поддерживает несколько десятков процессорных архитектур. ARM, x86, MIPS, SPARK, PowerPC — только самые известные из них. Процесс сборки тулчейна осложняется еще и тем, что в общем случае в него вовлечены три машины:
- build [англ. строить] — машина, на которой выполняется сборка тулчейна.
- host [англ. хозяин] — машина, на которой собранный тулчейн будет работать.
- target [англ. цель] — машина, для которой этот тулчейн будет генерировать код.
Каждая из них может иметь любую из поддерживаемых архитектур. Исходя из этого, различают несколько типов тулчейнов:
- Native-тулчейн [англ. native — родной], когда build = host = target. Все три архитектуры одинаковы. В качестве примера можно привести тулчейн, имеющийся в составе любого дистрибутива Linux. Он собран на машине с архитектурой x86, на ней же работает и для нее же компилирует программы.
- Cross-тулчейн [англ. cross — крест, перекрестный], когда build = host!= target. Тулчейн собирается и работает на машине с одной архитектурой, а генерирует код для машин с другой. Классический пример — кросс-тулчейны x86/ARM, активно применяемые при программировании для встроенных систем. Такой подход позволяет программисту комфортно работать и быстро компилировать код на мощном настольном компьютере, а слабую ARM-машину использовать только для тестирования уже готовой программы.
- Cross-native-тулчейн, когда build!= host = target.
- Canadian-тулчейн [англ. Canadian — канадский; намек на канадскую трехпартийную политическую систему], когда build!= host!= target.
Тулчейны первых двух типов используются наиболее часто; остальные имеют более узкие сферы применения.
Crosstool-NG
Столкнувшись с проблемой, всегда полезно поинтересоваться, что в подобной ситуации делают другие. Может быть, уже есть готовое решение. Сборка тулчейнов — как раз такой случай. Для ее автоматизации есть специальный инструмент — Crosstool-NG, проект с открытым исходным кодом, который уже много лет существует и активно развивается. Не вдаваясь в детали, можно считать, что он состоит из двух частей:
- Заимствованная из ядра Linux конфигурационная система; она позволяет задать для собираемого тулчейна необходимые параметры.
- Набор скриптов командной оболочки для выполнения сборки в соответствии с выбранной конфигурацией.
Пользовательский интерфейс Crosstool-NG прост. Тем, кто хоть раз собирал ядро Linux, он вряд ли покажется незнакомым. Главная проблема — разобраться в назначении параметров. К счастью, Crosstool-NG содержит множество готовых конфигураций, так что даже новичку есть с чего начать свои эксперименты. Кроме того, в архиве с исходным кодом (подкаталог docs) можно найти довольно содержательную документацию, а все этапы сборки тулчейна аккуратно заносятся в журнал. Это дает отличную возможность детально разобраться в процессе сборки, не изучая исходный код Crosstool-NG.
Пробуем Crosstool-NG
Попробуем собрать тулчейн. Пока, конечно, с помощью магии Crosstool-NG. Затем принципиальные противники чародейства и волшебства смогут проанализировать полученный журнал и научиться делать то же самое вручную.
Скачаем и распакуем последнюю версию Crosstool-NG:
Как и большинство других проектов, Crosstool-NG имеет зависимости, поэтому сначала необходимо установить несколько пакетов ПО. В Ubuntu 16.04 LTS это можно сделать так:
Сборка не отличается оригинальностью:
Ключ enable-local означает, что пользователь не собирается устанавливать Crosstool-NG в систему. Это никак не ограничивает функциональность, просто все команды придется запускать из каталога ./crosstool-ng-1.23.0. Зато для полного удаления Crosstool-NG достаточно будет лишь удалить этот каталог.
Всё, Crosstool-NG готов к работе. Но прежде чем начать его использовать, стоит познакомиться с соглашением именования тулчейнов. Оно довольно простое. Название тулчейна должно состоять из четырех компонентов, разделенных дефисами: — — —
, где
Итак, возвращаемся к Crosstool-NG. Попробуем собрать cross-тулчейн x86/ARM. Посмотрим список доступных примеров конфигураций и возьмем один из них за основу:
Кажется, arm-unknown-linux-gnueabi — неплохой вариант.
А так можно посмотреть краткую справку о его параметрах:
Если всё устраивает, выбираем его:
При необходимости можно запустить систему конфигурации, чтобы подробнее изучить параметры или откорректировать их:
Теперь остается только запустить сборку и дождаться ее окончания:
Это может занять несколько десятков минут, в зависимости от мощности рабочего ПК.
Что получилось
Если последняя команда завершилась без ошибок, Crosstool-NG успешно справился с задачей. А это значит, что в $
Начнем с самого интересного. Файл build.log.bz2 — это подробный журнал, по которому легко восстановить каждую команду, необходимую для сборки тулчейна.
Каталог bin можно назвать пользовательским интерфейсом тулчейна. В нем лежат компиляторы и полный набор утилит из пакета binutils. Вся полезная работа выполняется через них. У имени каждой программы есть префикс -. Например, компилятор gcc в данном случае будет называться arm-unknown-linux-gnueabi-gcc. Часто для удобства путь к этому каталогу добавляют в переменную окружения $PATH. Префикс позволяет избежать конфликта имен при одновременном использовании нескольких тулчейнов.
Каталог arm-unknown-linux-gnueabi/sysroot содержит полный набор системных заголовочных файлов, а также библиотек и программ, собранных под целевую архитектуру (в данном случае, ARM). Они реализованы в разных компонентах тулчейна и необходимы для сборки любого прикладного ПО. Кроме того, они обязательно должны присутствовать в корневой файловой системе (КФС) целевой машины. Фактически, sysroot — это почти готовая КФС. Достаточно добавить в нее busybox (набор UNIX-утилит командной строки, реализованный в виде одного исполняемого файла; часто используется во встраиваемых системах) и ядро Linux, чтобы получить минимальный дистрибутив, пригодный для запуска на машине с подходящей процессорной архитектурой.
Каталог arm-unknown-linux-gnueabi/debug-root можно считать дополнением к sysroot. Он содержит программы и библиотеки, предназначенные для отладки. Например, библиотеку libduma.so для поиска утечек памяти, трассировщики strace и ltrace или отладчик gdb.
Остальные каталоги имеют служебное значение. Они, конечно, тоже важны, но служат для обеспечения работы перечисленных выше компонентов.
Как использовать
Попробуем новый тулчейн в деле. Начнем с простейшего примера — “hello, world” на С++.
Пусть его исходный код хранится в файле main.cpp. Поскольку он в нашем проекте единственный, никакие сборочные системы не понадобятся. Даже Makefile не нужен. Достаточно просто вызвать компилятор C++:
Однако в данном случае используется g++ из системного native-тулчейна, а следовательно, получается исполняемый файл hw для архитектуры x86_64 (если на рабочем ПК установлена 64-разрядная ОС). Это легко проверить командой file ./hw, которая наряду с прочей информацией о файле печатает и его целевую процессорную архитектуру. Ну и, конечно же, программа hw должна запускаться и печатать свое приветствие миру на рабочем ПК.
Чтобы собрать тот же код для архитектуры ARM, достаточно лишь заменить g++ на собранный ранее кросс-компилятор arm-unknown-linux-gnueabi-g++:
/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++ ./main.cpp -o hw
Путь к новому тулчейну не был добавлен в переменную окружения PATH, а потому его приходится явно указывать при вызове кросс-компилятора. Это, возможно, выглядит несколько громоздко, но на первых порах так понятней. Теперь полученный исполняемый файл hw не запускается на рабочем компьютере, ведь у него другая целевая архитектура. В этом легко удостовериться, вызвав команду file ./hw.
Возьмем пример посложнее: небольшой, но полноценный проект “GNU sed”. Скачаем его исходный код:
Распакуем полученный архив:
Это классический проект GNU, для сборки которого используется система autotools (еще ее называют GNU Build System). Такие проекты, как известно, собираются тремя командами ./configure && make && make install. Однако это самый простой вариант, когда всем конфигурационным ключам присваиваются значения по умолчанию, сборка выполняется в каталоге с исходным кодом (а значит, там же создаются все промежуточные файлы, необходимые в процессе сборки), а готовое ПО устанавливается в системные каталоги. Разумеется, перспектива затереть системную утилиту sed не радует. Поэтому придется использовать чуть более сложный вариант сборки.
Допустим, исходный код sed был распакован в каталог /home/ dmitry/tc/sed/. Создадим здесь подкаталоги build и install:
Из первого будем запускать скрипт configure, а потому все промежуточные файлы будут создаваться именно там. Второй укажем в ключе —prefix, который задает путь установки собранного ПО.
Результат сборки — утилиту sed — можно найти в ./install/ bin. Она, конечно, собрана с помощью системного native-тулчейна, а потому ее целевая архитектура совпадает с архитектурой рабочего ПК. Это можно проверить уже упоминавшейся выше командой file. Разумеется, ./install/bin/sed должна без труда запускаться. Например, вот простейший тест — замена во входном тексте ‘123′ символа 2 на A:
Как же собрать sed для машин с архитектурой ARM? Ответ на этот вопрос нетрудно найти в справочной информации скрипта configure. Получить ее можно так:
Оказывается, решение довольно простое: переменная окружения CC задает компилятор, а ключ —host — целевую архитектуру.
Очистим каталоги build и install, а затем попробуем собрать sed еще раз.
Проверяем целевую архитектуру собранной программы sed:
Алгоритм сборки тулчейна
Как уже было сказано, Crosstool-NG ведет подробный журнал, анализ которого позволяет восстановить точную последовательность выполненных команд и детально разобраться в процедуре сборки тулчейна. Однако не стоит с ходу погружаться в его изучение. Обилие низкоуровневых деталей может помешать «за деревьями разглядеть лес». Сначала гораздо полезнее получить общее представление об алгоритме сборки. Он отлично описан в документации Crosstool-NG (docs/9_Toolchain_Construction.md). Этот раздел статьи — лишь краткий пересказ изложенных там идей. Конечно, при наличии свободного времени и хотя бы минимальных знаний английского языка лучше обратиться к оригиналу.
Компоненты тулчейна зависят друг от друга. Следовательно, важен порядок их сборки. Но это еще полбеды, главная проблема — в циклической зависимости между GCC и libc. GCC должен уметь использовать libc, а для сборки libc необходим GCC. «Проблема курицы и яйца», как говорят любители метафор. С первой зависимостью ничего сделать нельзя, а вот от второй легко избавиться. Это возможно благодаря тому, что для сборки libc вполне подходит ограниченная версия GCC, которую можно собрать специально для этой цели. В терминологии Crosstool-NG она называется “pass-2 core C compiler”. К сожалению, этому вспомогательному компилятору тоже нужна libc, но не вся, а лишь ее небольшая часть: заголовочные и стартовые файлы. Стартовые файлы по-другому называют CRT или “С runtime” (от англ. run time — период выполнения). Для их сборки можно использовать еще более урезанную версию GCC, которая от libc совершенно не зависит. Ее в Crosstool-NG называют “pass-1 core C compiler”.
Кроме того, надо не забыть учесть еще несколько зависимостей. Во-первых, для libc необходимы заголовочные файлы ядра Linux. Во-вторых, GCC генерирует код ассемблера, для компиляции которого в машинный код требуется binutils. В-третьих, GCC зависит от вспомогательных библиотек GMP, MPFR и MPC, а при определенной конфигурации — еще и от PPL, ISL, CLooG и libelf. Некоторые из них также зависят друг от друга, а потому обязательно должны собираться в указанном порядке. Это сложные математические библиотеки. Их детальное рассмотрение выходит за рамки данной статьи. Подробное обсуждение этой темы без погружения в архитектуру GCC и теорию построения компиляторов совершенно невозможно. Тем не менее, ниже назначение каждой библиотеки будет кратко описано. Однако эту информацию скорее стоит рассматривать лишь как материал для формирования поисковых запросов.
В итоге получается такая последовательность сборки:
- GMP (GNU Multi-Precision Library) — библиотека для вычислений с числами произвольной точности.
- MPFR (Multiple-Precision Floating-point computations with correct Rounding) — библиотека для вычислений с плавающей запятой произвольной точности и корректным округлением. Зависит от GMP.
- MPC (Multiple-Precision Complex) — библиотека для вычислений с комплексными числами произвольной точности. Зависитот GMP и MPFR.
- PPL (Parma Polyhedra Library) — библиотека для работы с полиэдрами (родилась в университете итальянского города Парма). Зависит от GMP.
- ISL (Integer Set Library) — библиотека для манипулирования целочисленными множествами и отношениями между ними.
- CLooG (Chunky Loop Generator) — генератор циклов в полиэдральной модели. Библиотека, используемая GCC для оптимизации генерации кода. Она является частью проекта Chunky [англ. плотный, коренастый], исследовательского инструмента, применяемого для улучшения локальности данных.
- libelf — библиотека для работы с форматом ELF (основной формат исполняемых файлов в ОС Linux).
- binutils.
- pass-1 core C compiler.
- заголовочные файлы ядра Linux.
- заголовочные и стартовые файлы libc.
- pass-2 core C compiler.
- полная версия libc.
- полная версия GCC.
Это основные компоненты тулчейна. Их сборка дает полноценный компилятор. При необходимости с его помощью нетрудно собрать дополнительные компоненты. Например, отладочные инструменты (gdb, duma, dmalloc, strace, ltrace).
Источник
