что такое кросс компиляция
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Кросс-компилятор
Содержание
Применение кросс-компиляторов
Канадский крест
Канадский крест-это техника построения кросс-компиляторов для других машин. Система конфигурирования и сборки GNU позволяет собирать программы, которые запускаются на системе, отличной от той, на которой собирались необходимые средства. Иными словами, она поддерживает сборку программ с помощью кросс-компилятора.
При использовании канадского креста c GSS могут быть четыре вида:
Конечный результат кросс-компилятор (4) не сможет работать на построение машины А; вместо этого она будет работать на машине B для компиляции приложения в исполняемый код, чтобы потом быть скопированным на машину C и выполненным на компьютере С.
Термин канадский крест возник потому, что в то время, когда эти проблемы обсуждались, в Канаде было три национальных политических партии.
Кросс-компиляция с GCC
GCC, бесплатная программа из коллекции компиляторов, может быть настроена для кросс компиляции. Она поддерживает множество платформ и языков.
Кросс-компиляцией GCC требует, чтобы часть стандартной библиотеки целевой платформы C была доступна на хост-платформе. Программист может выбрать для составления полную библиотеку C, но этот выбор может быть ненадежным. Альтернативой является использование файла, который представляет собой небольшую библиотеку C, содержащий только самые необходимые компоненты, необходимые для компиляции C в исходный код.
Бесплатный Pascal
Бесплатный Паскаль был разработан с самого начала в качестве кросс-компилятора. Исполняемый файл компилятора (ppcXXX где XXX-целевая архитектура) способен производить исполняемые файлы для всех ОС той же архитектуры. Например, ppc386 способен производить исполняемые файлы для i386-Linux, для i386-Win32 и для i386-go32v2 (DOS) и всех других ОС. Для компиляции на другой архитектуре архитектура кросс-версии компилятора должна быть построена первой.
Что такое кросс-компиляция?
что такое перекрестная компиляция?
Кросс-компиляция – это акт компиляции кода для одной компьютерной системы (часто называемой целевой) в другой системе, называемой хостом.
Это очень полезный метод, например, когда целевая система слишком мала для размещения компилятора и всех соответствующих файлов.
Общие примеры включают множество встроенных систем, но также типичные игровые консоли.
“Перекрестная компиляция” заключается в том, чтобы скомпилировать исходный код, скажем, в ящик Linux с намерением запустить его в окне MAC или Windows. Обычно это делается с использованием плагина перекрестной компиляции, который легко доступен с различных веб-серверов по сети. Если вы хотите установить плагин кросс-компиляции в свой Linux-блок, который предназначен для компиляции для окон Windows. Затем они могут компилироваться либо в поле Linux/* NIX, либо в качестве опции для компиляции и соединения исполняемого файла Windows. Это чрезвычайно удобно для внештатного программиста, у которого есть доступ к одному ядру Linux/Windows/MAC. Обратите внимание, что различные плагины для кросс-компиляции позволят использовать множество приложений, некоторые из которых вы можете или не можете воспринимать как полезные, таким образом, тщательное прочтение файла README плагина.
У вас есть определенный проект, который вы хотели бы применить к методу кросс-компиляции?
Кросс-компилятор компилирует исходный код из одной архитектуры в другую.
Этот процесс называется кросс-компиляцией.
см. ссылку для получения дополнительной информации кросс-компиляция
В строгом смысле, это компиляция кода на одном хосте, предназначенная для запуска на другом.
Чаще всего он используется со ссылкой на компиляцию для архитектур, которые не совместимы с двоичным кодом с хостом – например, создание двоичных файлов RISC на платформе CPU CISC или 64-разрядные двоичные файлы в 32-разрядной системе. Или, например, создание прошивки, предназначенной для работы на встроенных устройствах (возможно, с использованием архитектуры процессора ARM) на компьютерах на базе ПК на базе ПК.
Кросс-компилятор – это компилятор, способный создавать исполняемый код для платформы, отличной от той, на которой работает компилятор.
Например, компилятор, работающий на ПК с Windows 7, но генерирующий код, работающий на смартфоне Android, является кросс-компилятором.
Кросс-компилятор необходим для компиляции нескольких платформ с одного компьютера.
Платформа может быть недоступна для запуска компилятором, например, для микроконтроллера встроенной системы, поскольку эти системы не содержат операционной системы.
При паравиртуализации на одной машине работает много операционных систем, и кросс-компилятор может сгенерировать исполняемый файл для каждой из них из одного основного источника.
Русские Блоги
Подробное объяснение кросс-компиляции
Глава 1 Введение в кросс-компиляцию
1.1 Что такое кросс-компиляция
Те, кто еще не занимался встроенным программированием, могут не понимать концепцию кросс-компиляции, так что же такое кросс-компиляция? Что оно делает?
Прежде чем объяснить, что такое кросс-компиляция, вы должны сначала понять, что такое локальная компиляция.
Под локальной компиляцией можно понимать, что при текущей платформе компиляции скомпилированная программа может быть запущена только под текущей платформой. Обычно наша общая разработка программного обеспечения относится к локальной компиляции:
Например, на платформе x86 мы пишем программы и компилируем их в исполняемые программы. Таким образом, мы используем инструменты на платформе x86 для разработки исполняемых программ для самой платформы x86. Этот процесс компиляции называется локальной компиляцией.
Кросс-компиляция может быть понята как то, что под текущей платформой компиляции скомпилированная программа может работать на другой целевой платформе с другой архитектурой, но сама платформа компиляции не может запустить программу:
Например, на платформе x86 мы пишем программы и компилируем их в программы, которые могут работать на платформе ARM. Скомпилированные программы не могут работать на платформе x86, и для запуска их необходимо поместить на платформу ARM.
1.2 Почему происходит кросс-компиляция
Основная причина кросс-компиляции:
1.3 Почему кросс-компиляция трудна?
Сложность кросс-компиляции заключается в двух аспектах:
Разные архитектуры имеют разные характеристики машины
Среда хоста отличается от целевой среды во время кросс-компиляции
Для подробного сравнения, пожалуйста, обратитесь к этой статье, которая была написана подробно, поэтому я не буду вдаваться в подробности здесь:Introduction to cross-compiling for Linux
Глава 2 Кросс-компиляция цепочки
2.1 Что такое цепочка кросс-компиляции
Разберитесь, что такое кросс-компиляция, а затем давайте посмотрим, что такое цепочка кросс-компиляции.
Во-первых, процесс компиляции представляет собой сложный процесс, состоящий из различных подфункций и в порядке, как показано ниже:
Затем процесс компиляции включает в себя предварительную обработку, компиляцию, сборку, компоновку и другие функции. Поскольку существуют разные подфункции, каждая подфункция реализована в виде отдельного инструмента, которые вместе образуют полный набор инструментов.
В то же время процесс компиляции является последовательным процессом, который должен включать порядок, в котором используются инструменты. Каждый инструмент соединен последовательно в соответствии с последовательностью, которая образует цепную структуру.
следовательно, Кросс-компиляция цепочки Это полный набор инструментов, состоящий из нескольких подинструментов, сформированных для компиляции программного кода кроссплатформенной архитектуры. В то же время он скрывает детали предварительной обработки, компиляции, сборки, компоновки и т. Д. Когда мы указываем исходный файл (.c), он автоматически вызывает различные подинструменты в соответствии с процессом компиляции и автоматически генерирует окончательный образ двоичной программы (.bin). ).
Примечание. Строго говоря, кросс-компилятор ссылается на кросс-компилированный gcc, но на самом деле для удобства мы часто говорим, что кросс-компилятор представляет собой цепочку кросс-инструментов. В этой статье не проводится различие между этими двумя понятиями, оба относятся к цепочке компиляции
2.2 Правила именования цепочек кросс-компиляции
Когда мы используем цепочки кросс-компиляции, мы часто видим такие имена:
Среди них соответствующий префикс:
Правила именования этих цепочек кросс-компиляции кажутся универсальными, и существуют определенные правила:
Примечание. Это правило является предположением и не встречалось ни в одном официальном документе. Более того, наименование некоторых цепочек компиляции не следует этому правилу, и неясно, вызвано ли это историческими причинами. Если кто-то видел подробное описание этого правила в информации, пожалуйста, укажите на ошибку.
Глава 3 включены инструменты
3.1 Binutils
Подпрограммы, включенные в инструмент Binutils:
3.2 GCC
Пакет компиляторов GNU поддерживает C, C ++, Java, Ada, Fortran, Objective-C и многие другие языки.
3.3 GLibc
Поскольку ресурсы встроенной среды чрезвычайно ограничены, помимо glibc, на выбор есть uClibc и eglibc. Отношения между ними можно найти в этих двух статьях:
3.4 GDB
GDB используется для отладки программ
Глава 4 Как получить цепочку кросс-компиляции
Теперь, когда мы понимаем функцию цепочки кросс-компиляции, где мы получаем цепочку кросс-компиляции, которая нам нужна при разработке для встроенных систем?
Есть три основных способа получения
4.1 Загрузить уже подготовленную цепочку кросс-компиляции
Используйте цепочки кросс-компиляции, скомпилированные другими для определенных платформ ЦП. Нам просто нужно найти правильный, скачать его и использовать.
Адрес загрузки общей цепочки кросс-компиляции:
Инструменты, предоставляемые производителем, как правило, тщательно тестируются и имеют некоторые необходимые исправления, поэтому этот метод часто является наиболее надежным источником инструментов.
4.2 Используйте инструменты для настройки цепочки кросс-компиляции
Используйте существующие производственные инструменты, чтобы упростить создание цепочек кросс-компиляции. Нам нужно только понять, какие инструменты доступны, выбрать подходящий инструмент и понять этапы его работы.
Существует множество инструментов, каждый из которых имеет свои преимущества и недостатки. Вы можете изучать его медленно, поэтому я не буду вдаваться в подробности.
4.3 Построение цепочки кросс-компиляции с нуля
Это наиболее сложный и трудоемкий процесс. В конце концов, чтобы создать такую цепочку кросс-компиляции, вам необходимо хорошо понимать принцип встроенной компиляции. По крайней мере, вам нужно знать, куда обращаться, чтобы прочитать информацию в случае возникновения проблемы. Кроме того, это также место, где испытывают наибольшее терпение и осторожность.Если вы не соответствуете варианту или шагу, у вас могут возникнуть проблемы, которых вы никогда раньше не видели, и эти проблемы часто не связаны напрямую с этим параметром или шагом.
Конечно, если он собран, он, безусловно, будет самым полезным. По крайней мере, процесс компиляции и зависимости относительно ясны. Детали, возможно, должны пройти через соответствующий протокол или стандарт, но, по крайней мере, скелет будет более понятным.
Для подробного процесса строительства, пожалуйста, обратитесь к последующим статьям, в которых есть подробные параметры и шаги:
Подробное объяснение кросс-компиляции 2 Создание цепочки кросс-компиляции из нуля
Чтобы помочь каждому построить цепочку кросс-компиляции, я написал сценарий, сгенерированный одним щелчком мыши (включая загрузку исходного кода и автоматическую компиляцию). Если вам не удалось создать его самостоятельно, вы можете попробовать этот сценарий, а затем сравнить, является ли ваш процесс согласованным и отличаются ли параметры. Возможно, это поможет вам преодолеть это препятствие:
Подробное объяснение кросс-компиляции 3 Используйте скрипт для автоматической генерации цепочки кросс-компиляции
Кросс-компиляция в docker. Почему бы и нет?
Что такое кросс-компиляция? Какие есть инструменты для сборки бинарных файлов для Windows в Linux? Как настроить docker-контейнер для всего этого? Вот лишь небольшая часть вопросов, которые будут обсуждаться ниже.
Инструменты
Кросс-компиляция позволяет получить исполняемый код для платформы, отличной от той, на которой запускается этот процесс.
В рамках данной статьи рассмотрим кросс-компиляцию для платформы Windows в Linux.
Примером кросс-компилятора может служить Mingw-w64. По сути он предоствляет лишь инструмент для сборки приложения, но, если Вам необходимы сторонние библиотеки, которые не являются частью STL, придется собирать их и зависимости. Так же можно использовать готовые бинарные файлы, так как это описано в этой статье.
Упростить настройку сборки позволяет проект mxe, который предоставляет не только инструменты, но и библиотеки. С их списком можно ознакомиться на официальном сайте. При установке библиотек используется контроль зависимостей, т.е. будет установлен требуемый пакет и все необходимое для его работы. Инструменты поставляются в пред-настроенной конфигурации, например, для статической сборки 64-битных приложений. Это существенно облегчает сборку.
Среда mxe разворачивается в локальной папке пользователя. Для этого достаточно установить зависимости через пакетный менеджер и клонировать репозиторий. В корне репозитория находится Makefile, который и выполняет установку заданных в целях библиотек, добавляет инструменты для сборки и т.д.
Важно отметить, что среда сборки локализуется в пределах своей папки, это позволяет настроить индивидульную среду под каждое приложение.
Контейнеризируй это
Допустим, что сборка релиза для Windows у нас настроена на локальной машине. Релизы выходят довольно часто, в некоторых версиях добавляются новые библиотеки, а, некоторые, например, удаляются. В один прекрасный день начальник требует скинуть сборку релиза на новичка. Как ему настроить свою среду сборки? Какие библиотеки нужно взять из репозитория mxe, а для каких выполнить сборку из исходников?
На этот случай можно завести bash-скрипт, который будет разворачивать всю среду в заданной папке. И после пытаться поддерживать этот скрипт в актуальном состоянии. Но, как и документация к проекту, в один критически важный момент он может устареть.
Хорошим решением будет изолировать нашу среду для сборки внутри docker-контейнера. Сам docker-файл будет содержать самодостаточный набор инструкций по развертыванию среды, а наличие контейнера позволит избежать захламления домашней системы лишними библиотеками.
Собираем все вместе
Для демонстрации возьмем простой Qt-проект — SimpleQtProject. Этот проект собирается утилитой qmake, и состоит из одной единственной формы. Сделано это, конечно же, для простоты. Так же в папке docker лежит файл для сборки контейнера.
Рассмотрим docker-файл проекта. По сути он состоит из нескольких основных частей:
Ниже рассмотрены лишь основные команды из файла, для полного ознакомления рекомендуется обратиться к репозиторию.
Пропустим первый пункт и перейдем непосредственно к установке mxe.
Клонируем репозиторий:
На момент написания статьи последним релизом был build-2019-06-02. Здесь не используется ветка мастер по простой причине: необходима повторяемость сборки. В противном случае, при добавлении новых коммитов в мастер сборка может сломаться.
Далее настраиваем систему сборки:
Данная команда добавит инструменты (экземпляры cmake и Mingw-w64 и пр.) для статической сборки проекта под 64-битную архитектуру, а после соберет с их помощью Qt.
Следующим шагом добавим в PATH путь к исполняемым файлам mxe:
После того, как среда сборки настроена, можно перейти непосредственно к последнему пункту:
Здесь следует пояснить несколько моментов. Предполагается, что при запуске контейнера, в папку /app/src/ будет смонтирована папка с исходниками, содержащая *.pro файл, а в директории /app/res/ смонтировано место, куда следует сложить результаты сборки.
Ниже приведен пример команды для создания docker-image, ее необходимо запускать в папке docker рассматриваемого проекта:
Сборка же запускается там же:
Перед выполнение команды необходимо создать папку result в директории docker для копирования результатов.
Кастомизация сборки
По умолчанию mxe предоставляет MinGW версии 5.5.0 (по крайней мере это справедливо для сборки build-2019-06-02).
Если в проекте используются новые фичи С++ 17, то такая версия компилятора неудовлетворительна. К счастью, среда сборки предоставляет более новые версии в виде отдельных плагинов. Для решения нашей задачи, необходимо в команду сборки библиотек добавить инструкцию по использованию соответствующего плагина:
Данная команда создаст комплект для статической сборки 64-битных приложений с использованием компилятора седьмой версии (7.4.0). Если такой комплект уже существует, то он изменен не будет.
Со списком всех доступных плагинов можно ознакомиться на странице.
В директории mxe/src содержатся *.mk файлы, которые описывают параметры сборки того или иного пакета. При необходимости можно внести требуемые коррективы в уже существующий пакет или добавить свой собственный. Структура файлов описана вот тут — https://github.com/mxe/mxe/wiki/Add-a-New-Package:-Full-Version.
Для копирования pзависимостей проект mxe предоставляет утилиту copydlldeps.sh. Но это не единственный полезный инструмент, с их олным списокм можно ознакомиться на странице.
CMake и статическая линковка Qt
Так сложилось, что в своем проекте я использовал Qt и систему сборки CMake. Когда было принято решение о сборке проекта для Windows, отличным решением выглядело собрать все используя статическую линковку, чтобы пользователям предоставлять один бинарь, без каких-либо зависимостей.
Разбирая целую гору ошибок линковщика, удалось выяснить, что такая сборка из коробки не работает, вообще нигде. Дело в том, что qmake при использовании статической линковки генерирует *.cpp-файл, в котором находятся инструкции по импортированию плагинов, примерно такого вида:
Так же добавляются флаги и библиотеки для этапа линковки в Makefile.
Можно попробовать поэкспериментировать вот с такой конструкцией в CMakeLists.txt:
В конце концов, я пришел к решению динамически линковать (по возможности) все внешние библиотеки и копировать вместе с исполняемым файлом еще и необходимые dll с помощью copydlldeps.sh. Более подробно про разворачивание под Qt под Windows описано в статье.
В заключении
Выше было показано, как за несколько простых шагов можно настроить среду для кросс-компиляции проекта. Но, к сожалению, в реальных условиях все не так радужно.
Хоть проект mxe предоставляет внушительный список библиотек, но все равно он может не включать тех, которые нужны именно Вам, или включать слишком новые версии. Да, есть возможность самому создать пакет или, на худой конец, собрать библиотеку из исходников. Но не все можно сбилдить кросс-компилятором, так мне не удалось сделать это с проектом cpprestsdk, потому что ему нужен установленный vcpkg.
Это дело каждого — использовать кросс-компиляцию или нет. Мне это принесло неплохой профит. Я настроил сборку под несколько дистрибутивов Linux и Windows в отдельных docker-контейнерах для своего проекта SecureDialogues, добавил один make-файл для запуска процесса поочередно для каждого контейнера. Далее запускаю make и через некоторое время получаю бинарные файлы для требуемых ОС в локальной папке.
Кросскомпиляция под ARM
Достаточно давно хотел освоить сабж, но всё были другие более приоритетные дела. И вот настала очередь кросскомпиляции.
В данном посте будут описаны:
Вводная
Одно из развивающихся направлений в современном IT это IoT. Развивается это направление достаточно быстро, всё время выходят всякие крутые штуки (типа кроссовок со встроенным трекером или кроссовки, которые могут указывать направление, куда идти (специально для слепых людей)). Основная масса этих устройств представляют собой что-то типа «блютуз лампочки», но оставшаяся часть являет собой сложные процессорные системы, которые собирают данные и управляют этим огромным разнообразием всяких умных штучек. Эти сложные системы, как правило, представляют собой одноплатные компьютеры, такие как Raspberry Pi, Odroid, Orange Pi и т.п. На них запускается Linux и пишется прикладной софт. В основном, используют скриптовые языки и Java. Но бывают приложения, когда необходима высокая производительность, и здесь, естественно, требуются C и C++. К примеру, может потребоваться добавить что-то специфичное в ядро или, как можно быстрее, высчитать БПФ. Вот тут-то и нужна кросскомпиляция.
Если проект не очень большой, то его можно собирать и отлаживать прямо на целевой платформе. А если проект достаточно велик, то компиляция на целевой платформе будет затруднительна из-за временных издержек. К примеру, попробуйте собрать Boost на Raspberry Pi. Думаю, ожидание сборки будет продолжительным, а если ещё и ошибки какие всплывут, то это может занять ох как много времени.
Поэтому лучше собирать на хосте. В моём случае, это i5 с 4ГБ ОЗУ, Fedora 24.
Инструменты
Для кросскомпиляции под ARM требуются toolchain и эмулятор платформы либо реальная целевая платформа.
Т.к. меня интересует компиляция для ARM, то использоваться будет и соответствующий toolchain.
Toolchain’ы делятся на несколько типов или триплетов. Триплет обычно состоит из трёх частей: целевой процессор, vendor и OS, vendor зачастую опускается.
Сперва я пытался использовать toolchain’ы, которые лежат в репах Fedora 24. Но был неприятно удивлён этим:
Поискав, наткнулся на toolchain от компании Linaro. И он меня вполне устроил.
Второй инструмент- это QEMU. Я буду использовать его, т.к. мой Odroid-C1+ пал смертью храбрых (нагнулся контроллер SD карты). Но я таки успел с ним чуток поработать, что не может не радовать.
Элементарная технология кросскомпиляции
Собственно, ничего необычного в этом нет. Просто используется toolchain в роли компилятора. А стандартные библиотеки поставляются вместе с toolchain’ом.
Какие ключи у toolchain’а можно посмотреть на сайте gnu, в соответствующем разделе.
Для начала нужно запустить эмуляцию с интересующей платформой. Я решил съэмулировать Cortex-A9.
После нескольких неудачных попыток наткнулся на этот how2, который оказался вполне вменяемым, на мой взгляд.
Ну сперва, само собою, нужно заиметь QEMU. Установил я его из стандартных репов Fedor’ы.
Далее создаём образ жёсткого диска, на который будет установлен Debian.
По этой ссылке скачал vmlinuz и initrd и запустил их в эмуляции.
Далее просто устанавливаем Debian на наш образ жёсткого диска (у меня ушло
После установки нужно вынуть из образа жёсткого диска vmlinuz и initrd. Делал я это по описанию отсюда.
Сперва узнаём смещение, где расположен раздел с нужными нам файлами:
Теперь по этому смещению примонтируем нужный нам раздел.
Копируем файлы vmlinuz и initrd и размонтируем жёсткий диск.
Теперь можно запустить эмуляцию.
И вот заветное приглашение:
Теперь с хоста по SSH можно подцепиться к симуляции.
Теперь можно и собрать программку. По Makefile’у ясно, что будет калькулятор. Простенький.
Собираем на хосте исполняемый файл.
Отмечу, что проще собрать с ключом -static, если нет особого желания предаваться плотским утехам с библиотеками на целевой платформе.
Копируем исполняемый файл на таргет и проверяем.
Собственно, вот такая она, эта кросскомпиляция.
UPD: Подправил информацию по toolchain’ам по комментарию grossws.