Linux cross compile makefile

Кросскомпиляция модуля helloworld

Добрый день.
Пытаюсь собрать модуль helloworld под другую машину. Хост x86_64, таргет armhf.
Установил кросскомилятор /usr/bin/arm-linux-gnueabihf-gcc, скачал исходники ядра под данную машину

/projects/linux-3.4.113/
Пытаюсь собрать (пробовал через makefile, переменные, но поскольку ничего не получилось, пытаюсь уже в лоб):
/usr/bin/arm-linux-gnueabihf-gcc -I

/projects/linux-3.4.113/ -c ./helloworld.c

(и много всяких мелких вариаций похожей команды)
На что раз за разом получаю ругань о том, что linux/modules.h не найден.
Может кто объяснить что я делаю не так, и как надо правильно? Исходный код helloworld:

Содержимое Makefile, которым пытался собирать модуль:

/projects/linux-3.4.113/include по крайней мере пути к хеадерам ядра идут начиная с этой точки.

/projects/linux-3.4.113/ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-gcc . Да, кроме самих исходников нужен будет конфиг ядра и подготовить дерево исходников для сборки модулей примерно так: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-gcc modules_prepare

1 ответ 1

Основные зависимости

Для сборки внешних модулей ядра обязательно надо иметь:

• Исходные кода ядра, крайне желательно точно той же версии, что и на запущенном ядре (достаточно будет заголовочные файлы ядра с Makefile ‘ами [содержимое пакета linux-headers* в большинстве пакетных дистрибутивов])
• Конфиг ядра под которое собираешь или максимально близкий.
• [Кросс-]компилятор, make и прочую dev-мишуру

Типовая структура

hello.c:

Kbuild или Makefile, первое предпочтительнее. В простейшем случаее содержит одну строчку:

Подготовка дерева исходников ядра

Далее подразумевается, что исходники ядра распакованы в /tmp/linux , префикс кросс компилятора armv6j-hardfloat-linux-gnueabi , а целевая архитектура arm .

Желательно сделать oldconfig и ответить на сотню другую вопросов, но вполне хватит и silentoldconfig. Внимание на — в конце CROSS_COMPILE — это не ошибка, так и должно быть.

Стоит проверить, что поддержка модулей в ядре включена:

Подготовка дерева для сборки модулей:

Перед кросс компиляцией настоятельно советую потренироваться и собрать helloworld для текущего нативного ядра, всё точно также, но не надо указывать CROSS_COMPILE и ARCH .

Источник

Кросс-компиляция в 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:

А дальше добавить в target_link_libraries использование plugin_libs . Но для меня такой подход не принес никаких результатов.

В конце концов, я пришел к решению динамически линковать (по возможности) все внешние библиотеки и копировать вместе с исполняемым файлом еще и необходимые dll с помощью copydlldeps.sh. Более подробно про разворачивание под Qt под Windows описано в статье.

В заключении

Выше было показано, как за несколько простых шагов можно настроить среду для кросс-компиляции проекта. Но, к сожалению, в реальных условиях все не так радужно.

Хоть проект mxe предоставляет внушительный список библиотек, но все равно он может не включать тех, которые нужны именно Вам, или включать слишком новые версии. Да, есть возможность самому создать пакет или, на худой конец, собрать библиотеку из исходников. Но не все можно сбилдить кросс-компилятором, так мне не удалось сделать это с проектом cpprestsdk, потому что ему нужен установленный vcpkg.

Многие проблемы, которые могут появиться при сборке проекта кросс-компилятором, характерны для кросс-платформенной разработки вообще. Например, у меня была странная ошибка из-за элемента перечисления ERROR . Оказалось, что в одном из заголовочных файлов Windows имеется макрос с таким же именем. Его подстановка и ломала весь код.

Это дело каждого — использовать кросс-компиляцию или нет. Мне это принесло неплохой профит. Я настроил сборку под несколько дистрибутивов Linux и Windows в отдельных docker-контейнерах для своего проекта SecureDialogues, добавил один make-файл для запуска процесса поочередно для каждого контейнера. Далее запускаю make и через некоторое время получаю бинарные файлы для требуемых ОС в локальной папке.

Источник

How to modify Makefile to support cross compilation?

I have the following Makefile:

I execute it with the following command:

But it ignores ARCH and CROSS_COMPILE values. I tried to replace $(CC) with $(MAKE) and added -$(MAKEFLAGS) , but it was saying Nothing to be done for ‘Main.cpp’ .

How can I fix it and add cross compilation support?

2 Answers 2

The things you are passing to make (e.g. ARCH=$TARGET_ARCH ) are really just Makefile variables . make doesn’t know at all that they are related to cross-compilation (this is just something that you associate in your brain). E.g.

The standard way to do cross-compilation is to just override the compiler/linker. E.g. the following would cross-compile for i686-w64-mingw32 :

a few notes

Your makefile has a number of issues.

variable names

CC is the standard variable for the C-Compiler; for a C++-compiler use CXX

linking order matters

Modern linkers will discard unused symbols, leading to possible linker errors if you don’t get the order right. Therefore you should puts the $(LIBS) variable at the very end of your linker-invocation

declare dependencies

The power of make really is in the ability to resolve dependencies (finding out which parts of the build tree need to be recompiled when a few files have changed). For this to work you need to write rules that encode these dependencies — rather than conjure arbitrary target names and force to rebuild everything.

Источник

Linux cross compile makefile

Cross-Compiling using makefile

• Subscribe to RSS Feed
• Mark Topic as New
• Mark Topic as Read
• Float this Topic for Current User
• Bookmark
• Subscribe
• Mute
• Printer Friendly Page

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

We have one existing application source which uses Makefile which set the compiler with something like CC=$(CROSS_COMPILE)gcc.

I have two variables in makefile CROSS_COMPILE and SYSROOT, i am setting these variables as shown below

If I give make I am getting the below error.

../../Outils/GLOG/GLOG/src/IniParser/dictionary.h:36:19: fatal error: stdio.h: No such file or directory

Later I checked whether sysroot is set or not by using this command

And it gave output /not/exist it means sysroot is not set

So I have added —sysroot to my CFLAGS in Makefile and gave make

It gave the below errors

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find crt1.o: No such file or directory

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find crti.o: No such file or directory

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find crtbegin.o: No such file or directory

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find -lgcc

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find -lgcc_s

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find -lc

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find -lgcc

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find -lgcc_s

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find crtend.o: No such file or directory

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status

make[1]: *** [.so.1.0] Error 1

make[1]: Leaving directory `/home/linux/MorphoSmart_SDK_6.13.2.0_linux/PC/Sdk_linux/GLOG’

make: *** [lib] Error 1

.o’s are getting generated, but it is throwing error when it is trying to generate library

I don’t have any other way to compile other than using Makefile. Because the project has so many source files in different folders.

Can anyone suggest where I am going wrong.

i.MX6UL

Linux

Yocto Project

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

Hi I solved my self. I changed the library path and sysroot path then it started working,

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

Hi I solved my self. I changed the library path and sysroot path then it started working,

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

I found that the problem is with the dynamically linked libraries. If i use static libraries the application is compiling perfectly.

If i generate my own shared libraray and use it to compile a application then it is giving the below error

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: skipping incompatible /opt/poky/1.8/sysroots/i686-pokysdk-linux/lib/libgcc_s.so.1 when searching for libgcc_s.so.1

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find /lib/libc.so.6

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find /usr/lib/libc_nonshared.a

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find /lib/ld-linux-armhf.so.3

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

First, environment should be set, and under this environment
makefile may be run. The following helps to setup the environment :

Have a great day,
Yuri

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

Hi Yuri​ I solved above issue by changing the —sysroot path and now I am getting new error

arm-poky-linux-gnueabi-gcc MSO_Version.o MSO_Connect.o MSO_errors.o -o bin/MSO_Version_shared -Wall -g -Os -fPIC -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 —sysroot=/home/fsl-release-bsp/build_image/tmp/sysroots/imx6ulevk -I../include -I../wsq -I/home/fsl-release-bsp/build_image/tmp/sysroots/imx6ulevk/usr/include/ -L/opt/poky/1.8/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi/usr/lib -L../lib -L/opt/poky/1.8/sysroots/i686-pokysdk-linux/lib -L/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/lib -L/home/fsl-release-bsp/build_image/tmp/sysroots/imx6ulevk/usr/lib -lMSO -lMSOComm -lusb

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: skipping incompatible /opt/poky/1.8/sysroots/i686-pokysdk-linux/lib/libgcc_s.so.1 when searching for libgcc_s.so.1

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find /lib/libc.so.6

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find /usr/lib/libc_nonshared.a

/opt/poky/1.8/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find /lib/ld-linux-armhf.so.3

collect2: error: ld returned 1 exit status

make[1]: *** [MSO_Version_shared] Error 1

make[1]: Leaving directory `/home/linux/ESYS-IMP-LINUXAPP-SUF-24092012-V0.01/Internal Release/ESYS-IMP-LinuxApp-SUF-LIB-SRS-V0.01/samples’

Источник