кросскомпиляция для arm под линукс

Кросс-компиляция под Linux

Введение

Что же у нас есть для кросс-компиляции? Если не считать коммерческих продуктов и мелких поделок, то для того, чтобы скомпилировать любой проект под любую платформу, понадобится Gnu Compiler Collection, или, кратко, GCC. GCC — это один большой набор исходников, но собирать из него кросс-компилятор на каждую новую целевую платформу придётся отдельно.

Надо сказать, список целевых платформ довольно внушителен.

Вообще, для того, чтобы работать с GGC надо собрать т. н. Toolchain, набор утилит для компиляции. В toolchain входит помимно GCC, ещё Binutils, предназначенные для манипуляций с объектными и бинарными файлами. Для голого железа (если планируется работать не под ОС на целевой платформы, весьма полезной будет также NewLib — сборник стандартных процедур.

Binutils

В составе GCC большой набор разнообразных инструментов, однако, скорее всего иметь дело придётся с frontend, который так и называется, gcc. Он сам определяет тип исходного файла и вызывает соответствующий компилятор, а также, по необходимости, линковщик или библиотекарь.

NewLib

NewLib — специальная подборка стандартных функций для встраиваемых систем. Она включает в себя libc (функци работы со строками, файлами и т. д.), libm (разнообразные математические функции). Также она обладает широкими возможностями конфигурирования под разнообразные требования.

Сборка Toolchain

Порядок сборки Toolchain

Сборка тулчейна в описанной конфигурации состоит из следующих этапов:

Источник

Инструменты кросскомпиляции для ARM

В сети есть достаточно много источников на тему сборки приложений под архитектуру ARM, но когда я впервые столкнулся с такой задачей, то набил не одну шишку. Этот топик будет про самые начала кросскомпиляции и различные подходы к этому вопросу.

Моё устройство принадлежит к архитектуре ARMv5TE и разработка велась на x86 машине с Ubuntu Linux.
Так как это введение, то собирать будем простую программу для высчитывания факториала числа.

Подход 1. Коммерческий.
Компанией CodeSourcery выпускается коммерческая интегрированная среду разработки Sourcery G++, основанная на инструментах GNU (gcc, gdb, binutils) и имеющая интерфейс на базе Eclipse. Пожалуй, это самый простой и быстрый способ создания приложений, так как при установке ставятся и все необходимые библиотеки, и сам кросскомпилятор. На официальном сайте кроме возможности покупки можно воспользоваться триальной версией на 30 дней. Благодаря близкому «родству» с Eclipse настройки интуитивно понятны и писать подробно нет смысла.

Для разовых задач подходит идеально, но есть и абсолютно бесплатные решения.

Подход 2. QEMU.
Широко известная программа эмуляции QEMU поддерживает в том числе и ARM платформу, чем грех не воспользоваться.

Для начала устанавливаем саму программу:

sudo apt-get install qemu-kvm-extras-static
Разработчики QEMU сделали отдельную команду для простоты установки окружения (в моём случае это debian lenny):

sudo build-arm-chroot lenny qemu
В ре­зуль­та­те у нас со­здаст­ся ка­та­лог qemu с об­ра­зом си­сте­мы lenny под нужную нам архитектуру.
Не хватает сети и необходимых пакетов для компиляции. Отредактируем sources.list нашей qemu-машины:
sudo nano qemu/etc/apt/sources.list

deb ftp.us.debian.org/debian lenny main contrib non-free
deb-src ftp.us.debian.org/debian lenny main contrib non-free

Обновляемся, устанавливаем необходимые пакеты и в самой QEMU собираем наш factorial.

Подход 3. Собираем crosstool.
Crosstool — это набор скриптов для сборки и проверки работы gcc и glibc для всех архитектур, поддерживаемых glibc. При сборке различных кросстулов (так или так) у меня возникали проблемы с совместимостью различных компонентов. Так, например, gcc не дружил с binutils из-за разницы в версиях и приходилось чуть ли не методом тыка подбирать работающие связки. К счастью, и этот процесс уже был автоматизирован и сделан предельно простым. За что спасибо пользователю сайта linux.org.ru mskmsk1985:
Написанный им скрипт собирает тулчейн для arm-linux-gnueabi- архитектуры из последних версий GNU инструментов. Собираются С и С++ кросс компиляторы, кросс-отладчик и отладочный сервер для целевой архитектуры. Подробнее можно прочитать тут.

Подход 4. Gentoo-way.
Как и писал, собиралось это всё на компьютере с Ubuntu, но стоит всё же сказать, что в Gentoo есть отдельная программа crossdev, которая занимается тем же самым и собирает бинарники для нужной архитектуры.

Подход 5. Ubuntu-way.
Мои долгие поиски наиболее простого способа кросскомпиляции шли весьма запутанно и, конечно же, я пропустил решение, которое было слишком очевидным и простым чтобы даже об этом думать. Но оказалось что да, кросскомпилятор можно поставить из репозиториев и одной командой:

sudo apt-get install libc6-dev-armel-cross gcc-arm-linux-gnueabi

Вместо заключения.
Способы кросскомпиляции не ограничиваются приведенными выше примерами. Существуют многостраничные описания, варианты создания необходимых инструментов ‘from scratch’, но если нужно быстро написать и запустить простенькое приложение на другой архитектуре, часто не хватает времени для полного изучения, да и количество нюансов и программных несовместимостей могут отбить любое желание заниматься этим.

Надеюсь, мой небольшой обзор поможет вам избежать моих ошибок и быстро получить работающий инструмент для создания приложение на ARM-архитектуре. Удачи!

Источник

Кросс-компиляция под ARM — Midnight Commander

Поэтому я посвящу пару записей на данную тему, поскольку подобные задачи недавно возникали у меня, с которыми мне все-таки удалось справится. И мне бы хотелось поделится полученным опытом с общественностью.

# apt-get install gcc-4.7-arm-linux-gnueabi
# apt-get install gcc-arm-linux-gnueabi
Это дело работает как gcc, вызывать компилятор можно так: arm-linux-gnueabi-gcc. Все возможности смотрите тут: man arm-linux-gnueabi-gcc.

Это минимальный список исходников, которые позволят успешно использовать mc. Я забочусь о читателях, поэтому архивчик со всеми необходимыми исходниками можно загрузить ниже (если ссылка битая, или еще чего нибудь приключилось, то придется искать самостоятельно).

Поэтому делаем следующее:

В каталог /tmp/mc_build/sources кладем наш архив mc_src.tar.gz и выполняем разархивацию в данный каталог содержимого всех архивов руками, либо так (перед выполнением сначала перейдите в каталог с архивом):

Создаем файл скрипта в корне:

Открываем его любым текстовым редактором, например:

Копируем в этот файл следующий текст:

Даем данному скрипту права на выполнение:

$ chmod 755 /tmp/mc_build/sources/check-0.10.0/my_make

И выполняем данный скрипт:

Таким же образом происходит компиляция всего остального (копируете скрипт my_make, даете ему права на исполнение, запускаете, надеетесь, чтобы не было ошибок). Поэтому далее я лишь приведу скрипты my_make для каждой библиотеки. Компилировать, кстати, библиотеки нужно в том порядке, в котором я привожу тексты скриптов.

Компиляция zlib-1.2.8:
UPD: У некоторых при использовании данного скрипта для компиляции zlib появляются ошибки вроде:

Логи configure.log говорят, что, почему то, arm-linux-gnueabi-gcc не понимает строку

Всем спасибо, ставьте лайки, подписывайтесь на мой канал, всем пока!

Архив со всеми исходниками: ССЫЛКА

23 thoughts on “ Кросс-компиляция под ARM — Midnight Commander ”

Замечательная статья дружище. Добавь пожалуйста что кроме установки gcc-4.7-arm-linux-gnueabi нужно еще установить arm-linux-gnueabi-gcc. А при сборке glib-2.44.1 нужно установить libglib2.0-dev иначе выдает ошибку и останов.

И еще. C ncurses проблемы — не компилится то не может найти заголовки то libs. Компилировал без него. Еще. Он не компилируется без библиотек slang. Нужно собирать и ее.

Спасибо за полезный комментарий!
Да, действительно, для корректной компиляции библиотек необходим еще пакет gcc-arm-linux-gnueabi. А для сборки glib может потребоваться библиотека libglib2.0-dev. Добавил изменения в статью.
Но вот на счет ncurses и slang — это две взаимозаменяемые графические библиотеки для mc. Поэтому одна не требует наличия другой. По умолчанию, mc компилируется с slang, но в данной статье использовалась библиотека ncruses. По функционалу для mc они практически не отличаются, поэтому с какой быстрее и удобнее собирать, ту и стоит выбрать. Если с ncurses не получается, то можно попробовать собрать с slang, но это чуть сложнее, поскольку у нее больше зависимостей.

Я видимо несколько сумбурно написал. Но Вы поняли мою мысль. Только что собрал mc с ncurses. Дело все в том, что у меня стояла задача скомпилировать mc под nas seagate central. Там немного хитрый arm-процессор поэтому обычно скомпилированный mc просто не запустится. Ваша статья очень помогла с основными моментами, спасибо. Я написал свою статью, естественно со ссылкой на Вашу, в которой указал дополнительные флаги, необходимые для правильной компиляции под тот процессор. Cсылку на нее я не привожу дабы не загаживать Вам ссылочную массу.

Здравствуйте. Подскажите новичку. Как Вы определяете что еще потребуется компилировать для нужной вам программы. Ну, почему для mc потребуются еще пять исходников?

Здравствуйте!
Ну первое, что следует читать перед компиляцией — это файл README, который должен находиться в корне исходников любой крупной программы. То есть обращаться к первоисточнику. Обычно (но не всегда) разработчики в данном файле описывают все основные моменты, которые должны знать пользователи. Например, в случае mc, в файле README в разделе Dependencies (зависимости) написано, что вся информация про установку mc находится в файле INSTALL — а там уже все подробно описано, какие библиотеки нужны для сборки данной версии программы.
Второй вариант, менее правильный — начать сборку программы сразу без чтения документации. Это работает только с крупными и известными программами с хорошими скриптами сборки. Потому что при сборке без нужных библиотек (обычно при запуске скрипта configure) в терминал будет выведена ошибка с наименованием библиотеки, которая требуется. Так, библиотеку за библиотекой по очереди добавлять, пока ошибки перестанут приходить.
Ну и третий вариант — воспользоваться Интернетом. В сети, особенно в англоязычном сегменте, наверняка имеются полные списки зависимостей для большинства крупных программ.
Данных трех вариантов мне всегда хватало для успешной компиляции большинства программ.

Извините за глупые вопросы, я с линуксом раньше дело не имел

Кажется понял. Скрипт Configure есть в каждой папке, и он является аргументом для компилятора

Да, скрипт configure присутствует во всех программах, которые используют утилиту Autoconf для сборки проекта.
В данной статье я предлагаю проводить сборку midnight commander с использованием своих собственных bash-скриптов. А в bash-скриптах первой строкой обязательно нужно обозначать путь в системе к bash-интерпретатору, который и выглядит обычно таким образом: #!/bin/bash.
Флагом ARCH обозначается архитектура, под которую производится кросс-компиляция. В данной статье производилась кросс-компиляция для процессоров arm.

И еще, насколько я помню, раньше были отдельно компилятор и отдельно линковщик. Сейчас все в одном?

Далее. Фраза: «Создаем файл скрипта в коре:»
Что такое коре, это специальный текстовый редактор?

Не совсем понимаю вопрос, что имеется в виду под «отдельно компилятор и линковщик»? Они до сих пор раздельны в этапах сборки программы и имеется возможность отдельно вызывать их по очереди. Это и происходит при сборке программы с помощью утилиты make, которую мы вызываем в скриптах в статье.

А на счет фразы — это была опечатка =) Имелось в виду, что необходимо создать пустой файл в корне каталога /tmp/mc_build/sources/check-0.10.0/my_make. Спасибо, что указали на опечатку!

Большое спасибо за ответы.
Это я по системе DOS помню что сначала компилировали, получали объектный файл, а потом выполняли link который был в комплекте компилятора и получали уже исполняемый файл. Тут видно уже эти операции совместили.
Я просто пытаюсь скомпилировать mc для платформы powerpc, вот и корректирую для него файлы makefile. Компилятор у него свой powerpc-e300c3-linux, на Hello words я его проверил, работает

Так же происходит и в Linux с использованием gcc — сначала все компилируется, преобразовываясь в объектные файлы, а далее все это собирается компоновщиком/линковщиком в исполняемый файл. Просто в данном случае используется специальная утилита make, которая сама за разработчика выполняет эти действия. Разработчик лишь настраивает её работу, указывая какие модули программного проекта необходимо компилировать. А в случае mc еще используется утилита Autoconf, которая создает конфигурационные скрипты (configure) под платформу и потом сама генерирует эти самые файлы — makefile, для которых достаточно вызвать make.

Все пытаюсь скомпилировать check-0.10.0
Подскажите, что я делаю не так?

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Check configure 0.10.0, which was
generated by GNU Autoconf 2.68. Invocation command line was

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /opt/wisermind_MPS83xx/
PATH: /usr/X11R6/bin
PATH: /root/bin

/* confdefs.h */
#define PACKAGE_NAME «Check»
#define PACKAGE_TARNAME «check»
#define PACKAGE_VERSION «0.10.0»
#define PACKAGE_STRING «Check 0.10.0″
#define PACKAGE_BUGREPORT «check-devel at lists dot sourceforge dot net»
#define PACKAGE_URL «»
#define PACKAGE «check»
#define VERSION «0.10.0»

Источник

Русские Блоги

Подробное объяснение кросс-компиляции

Глава 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 Используйте скрипт для автоматической генерации цепочки кросс-компиляции

Источник

Русские Блоги

Среда кросс-компиляции ARM-LINUX

В связи с необходимостью разработки приложений для руки необходимо создать среду компиляции для руки. Есть два способа создать среду:

Среда кросс-компиляции включает следующее:

Поскольку среда Linux более удобна в настройке, рекомендуется использовать среду Linux для разработки. Visual Studio удобнее разрабатывать, IDE лучше, но удобнее выбирать Linux + Makefile.

Построение среды Linux

Объяснение названия инструментария

Что такое аби и эаби

Полный ABI, такой как Intel Binary Compatibility Standard (iBCS), позволяет программам в операционных системах, которые его поддерживают, запускаться в других операционных системах, поддерживающих этот ABI, без изменений.
ABI отличается от интерфейса прикладного программирования (API), API определяет интерфейс между исходным кодом и библиотекой, поэтому один и тот же код может быть скомпилирован в любой системе, поддерживающей этот API, ABI позволяет компиляцию Хороший целевой код может работать без изменений в системе, использующей ABI-совместимую.

Основное различие между EABI и ABI на компьютерах общего назначения заключается в том, что привилегированные инструкции разрешены в коде приложения, динамическое связывание не требуется (иногда запрещено), а для экономии памяти используется более компактная структура стека. EABI широко используется Power PC и ARM.

Два кросс-компилятора, связанные с gnueabi: gnueabi и gnueabihf

Определения этих двух кросс-компиляторов в исходном коде debian следующие:

Видно, что эти два кросс-компилятора подходят для двух разных архитектур armel и armhf. Две архитектуры armel и armhf используют разные стратегии для операций с плавающей запятой (руки с fpu могут поддерживать эти две стратегии операций с плавающей запятой)

Жесткое плавание

Компилятор непосредственно компилирует код и передает его на аппаратный сопроцессор с плавающей запятой (арифметический блок с плавающей запятой FPU) для исполнения. FPU обычно имеет набор дополнительных регистров для завершения передачи параметров с плавающей запятой и вычислений.
Использование реального аппаратного блока FPU с плавающей запятой, конечно, приведет к повышению производительности. Потому что часто для вызова функции с плавающей запятой требуется несколько или десятки тактов.

Мягкий поплавок

Компилятор преобразует операции с плавающей запятой в вызовы арифметических функций с плавающей запятой и вызовы библиотечных функций.Нет вызова инструкций FPU и передачи параметров регистра с плавающей запятой. Передача параметров с плавающей запятой также осуществляется через регистры или стеки ARM.
Текущая система Linux предпочитает использовать по умолчанию для компиляции жесткое с плавающей запятой, даже если в системе нет процессора с плавающей запятой, это приведет к возникновению недопустимых инструкций и исключений. Поэтому в общих системных образах используется мягкая плавающая точка для совместимости с процессорами без VFP.

armel ABI и armhf ABI

Следует отметить, что с точки зрения совместимости soft и два последних совместимы, но два режима softfp и hard несовместимы.

Источник