- Arch Linux User Repository
- Search Criteria
- Package Details: arm-linux-gnueabihf-gcc 11.2.0-2
- Package Actions
- Dependencies (7)
- Required by (7)
- Sources (6)
- Latest Comments
- alzeha commented on 2020-06-27 09:55
- tavianator commented on 2020-06-23 16:53
- alzeha commented on 2020-06-23 15:03
- tavianator commented on 2020-06-10 20:50
- volker.raschek commented on 2020-06-10 20:44
- tavianator commented on 2020-06-10 20:33
- volker.raschek commented on 2020-05-30 21:10
- streblo commented on 2020-05-28 21:25
- tavianator commented on 2020-05-15 19:46
- felipebalbi commented on 2020-05-13 05:49
- Arch Linux
- #1 2019-01-23 23:17:45
- [SOLVED] missing arm-linux-gnueabihf-pkg-config
- #2 2019-01-24 02:28:36
- Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
- #3 2019-01-24 20:38:50
- Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
- #4 2019-01-25 11:02:00
- Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
- #5 2019-01-25 15:58:59
- Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
- Кросскомпиляция под ARM
- Вводная
- Инструменты
- Элементарная технология кросскомпиляции
- Как скомпилировать Qt для Arm под g++-arm-linux-gnueabihf?
Arch Linux User Repository
Search Criteria
Package Details: arm-linux-gnueabihf-gcc 11.2.0-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/arm-linux-gnueabihf-gcc.git (read-only, click to copy) |
---|---|
Package Base: | arm-linux-gnueabihf-gcc |
Description: | The GNU Compiler Collection (arm-linux-gnueabihf) |
Upstream URL: | https://gcc.gnu.org |
Licenses: | GPL, custom, LGPL, FDL |
Conflicts: | arm-linux-gnueabihf-gcc-stage1, arm-linux-gnueabihf-gcc-stage2 |
Provides: | arm-linux-gnueabihf-gcc-stage1=11.2.0, arm-linux-gnueabihf-gcc-stage2=11.2.0 |
Replaces: | arm-linux-gnueabihf-gcc-stage1, arm-linux-gnueabihf-gcc-stage2 |
Submitter: | tavianator |
Maintainer: | razykov |
Last Packager: | razykov |
Votes: | 75 |
Popularity: | 1.22 |
First Submitted: | 2015-09-14 15:41 |
Last Updated: | 2021-10-09 08:31 |
Dependencies (7)
Required by (7)
- arm-linux-gnueabihf-armcl-neon(make)
- arm-linux-gnueabihf-glibc (requires arm-linux-gnueabihf-gcc-stage2) (make)
- arm-linux-gnueabihf-glibc-headers (requires arm-linux-gnueabihf-gcc-stage1) (make)
- arm-linux-gnueabihf-musl(make)
- arm-linux-gnueabihf-ncurses(make)
- arm-linux-gnueabihf-openblas-lapack-openmp(make)
- hakchi-git(make)
Sources (6)
Latest Comments
alzeha commented on 2020-06-27 09:55
Sorry for the late reply. I am usually busy from Monday to Friday :/
tavianator commented on 2020-06-23 16:53
@alzeha: Do you have the file /usr/arm-linux-gnueabihf/lib/libpthread.so.0 present, from the package arm-linux-gnueabihf-glibc?
alzeha commented on 2020-06-23 15:03
does anyone else have something like this:
I do not see, what is happening here. I followed the order, given at the pinned comment.
This does not seem right, or? There is additional =?
tavianator commented on 2020-06-10 20:50
@volker.raschek: So yay just seems totally unable to resolve the dependency chain. That’s too bad, I know it used to work. Try installing everything in the order from the pinned comment.
volker.raschek commented on 2020-06-10 20:44
@tavianator: I’ve set LC_ALL and tried to install the arm-linux-gnueabihf-gcc-stage2 package manually with yay. I attached links to screenshots of the yay parms and the error below
tavianator commented on 2020-06-10 20:33
@volker.raschek: Possibly a bug in yay? If you try installing arm-linux-gnueabihf-gcc-stage2 manually does it work?
@streblo: More important than the compiler version is the version of the system libraries. I’m not sure what the relevant versions are for Debian, but you’d probably have more luck asking a Debian community.
volker.raschek commented on 2020-05-30 21:10
Failed to build the package with yay. Missing dependency arm-linux-gnueabihf-gcc-stage2.
Can anybody fix the error?
streblo commented on 2020-05-28 21:25
If I want a 8.3 toolchain for Debian buster is there an easy way to chase down which version of this package I need? Or can the host compiler be ahead of the target you are compiling for?
tavianator commented on 2020-05-15 19:46
@felipebalbi: I just updated everything. I credited you for the binutils patch since I took your solution to the conflicting files.
felipebalbi commented on 2020-05-13 05:49
@tavianator the reason I went with 10.1 is twofold:
If I was already updating, might as well update to the latest :-p
Anyway here are all commits which I’ve pushed to github mirrors of your AUR repositories:
Copyright © 2004-2021 aurweb Development Team.
AUR packages are user produced content. Any use of the provided files is at your own risk.
Источник
Arch Linux
You are not logged in.
#1 2019-01-23 23:17:45
[SOLVED] missing arm-linux-gnueabihf-pkg-config
I am trying to build ardupilot on my arch. I can do so on Ubuntu. I am missing arm-linux-gnueabihf-pkg-config program on arch. There is compiler arm-linux-gnueabihf-gcc in AUR but for some reason is not bundled with arm-linux-gnueabihf-pkg-config. Is there any reason why it was done like that. And more importantly how can I get arm-linux-gnueabihf-pkg-config in my arch? Can you sketch PKGBUILD for me?
Last edited by crazySocket (2019-01-27 13:03:59)
#2 2019-01-24 02:28:36
Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
That is because the program you are looking for is supposed to be a shellscript which
1) defines $PKG_CONFIG_LIBDIR as equal to the specific directory for your cross-compiler triple, which contains .pc files. That is to say, /usr/arm-linux-gnueabihf/lib/pkgconfig
2) exec pkg-config «$@»
On Arch Linux, the pkg-config implementation is in fact pkgconf, and it can additionally set PKG_CONFIG_SYSTEM_LIBRARY_PATH and PKG_CONFIG_SYSTEM_INCLUDE_PATH.
For details on how this works, Arch Linux has two supported architectures: i686-pc-linux-gnu (used in the [multilib] repository) and x86_64-pc-linux-gnu. You will notice that /usr/bin/i686-pc-linux-gnu-pkg-config and /usr/bin/x86_64-pc-linux-gnu-pkg-config therefore exist and are provided by the pkgconf package (along with /usr/bin/pkgconf, /usr/bin/pkg-config, and /usr/bin/pkg-config-32). All of these are that exact wrapper script with the exception of /usr/bin/pkgconf which all the rest are designed to execute after setting the necessary options.
Managing AUR repos The Right Way — aurpublish (now a standalone tool)
#3 2019-01-24 20:38:50
Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
Ok so I did cheat the build system into believing arm-linux-gnueabihf-pkg-config is available by making a shell script with content
Yet when I try to compile static executable I get error
/usr/bin/arm-linux-gnueabihf-ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
Did my pkg-config script not make a cut? I see the file /usr/arm-linux-gnueabihf/lib/libstdc++.so. Even added -L/usr/arm-linux-gnueabihf/lib/ to the /usr/bin/arm-linux-gnueabihf-g++. What is wrong?
#4 2019-01-25 11:02:00
Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
Why are you doing your best to avoid using a PKGBUILD ?
I’ve taken a quick peek and the riscv64 (3rd link) & aarch64 (1st link) mentioned by Eschwartz should be easy to adapt to arm-linux-gnueabihf architecture.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
Did you use the guided installer ? If yes, I can’t help you.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
#5 2019-01-25 15:58:59
Re: [SOLVED] missing arm-linux-gnueabihf-pkg-config
Why are you doing your best to avoid using a PKGBUILD ?
Because it is a trivial single shellscript. While I agree that files should be tracked using PKGBUILDs, this physically cannot be the problem the OP is having.
I’ve taken a quick peek and the riscv64 (3rd link) & aarch64 (1st link) mentioned by Eschwartz should be easy to adapt to arm-linux-gnueabihf architecture.
Of my three links, you chose the two which I consider philosophically wrong, and explicitly skipped the one which is done correctly.
There is an exceedingly good reason why pkg-config/pkgconf make these settings configurable — there is no earthly reason to build the same binary a hundred times, once for every target triple that people use. It’s a program that consists of:
1) predefined default paths that describe a native system, and cross-compiler environment variables to redefine these,
2) a parser for the .pc file format,
3) an option parser,
4) routines for combining the paths in #1 with the contents of the .pc file in #2
Absolutely none of this requires recompiling the default paths, and especially it makes no sense to cross-compile pkg-config itself to run on another target triple when the native triple works fine.. it is just a lot of pointless busy work.
without knowing what code you are trying to build or the exact command line being used, we cannot know. but pkg-config is merely supposed to help the build system learn what CFLAGS/LDFLAGS to use for dependencies, it cannot help if the build system does not actually use those everywhere that it needs to.
And libstdc++ doesn’t exactly have a .pc file anyway. It’s actually part of gcc-libs itself, and for the target triple arm-linux-gnueabihf it will be part of arm-linux-gnueabihf-gcc (that package doesn’t split out gcc/gcc-libs).
gcc itself is supposed to use the builtin spec to locate its own internal libraries for you.
Managing AUR repos The Right Way — aurpublish (now a standalone tool)
Источник
Кросскомпиляция под ARM
Достаточно давно хотел освоить сабж, но всё были другие более приоритетные дела. И вот настала очередь кросскомпиляции.
В данном посте будут описаны:
- Инструменты
- Элементарная технология кросскомпиляции
- И, собственно, HOW2
Кому это интересно, прошу под кат.
Вводная
Одно из развивающихся направлений в современном 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 зачастую опускается.
- *-none-eabi — это toolchain для компиляции проекта работающего в bare metal.
- *eabi — это toolchain для компиляции проекта работающего в какой-либо ОС. В моём случае, это Linux.
- *eabihf — это почти то же самое, что и eabi, с разницей в реализации ABI вызова функций с плавающей точкой. hf — расшифровывается как hard float.
Описанное выше справедливо для gcc и сделанных на его базе toolchain’ах.
Сперва я пытался использовать 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.
Источник
Как скомпилировать Qt для Arm под g++-arm-linux-gnueabihf?
Установил компилятор для работы с Arm (g++-arm-linux-gnueabihf, и gcc-multilib, g++-multilib для кроссплатформенной компиляции), настроил Kit’ы для работы с этим компилятором и подключенным устройством — все нормально работает с std c++11. Теперь хочу чтобы c Qt заработало. Мой план такой — скомпилировать Qt, подключить эту версию к существующему Киту, подключить Qt статически к своему проекту и выполнять целевую бинарку на Arm’е.
Буду благодарен за любые ваши указания советы, которые хочу почитать перед началом конфигурации/компиляции/инсталяции, чтобы не наступать на те же грабли.
Qt хочу скомпилировать 5.7
OS хоста Ubuntu 15.10 64bit
на Arm стоит 32 бита Debian GNU/Linux 7
Важно, что никакую графику на Арме выполнять не нужно, по-моему это должно облегчить задачу. Тип проекта будет Qt based console C++
Хороша ли, например, такая кофигурация:
./configure -prefix /home/[myname]/Qt-custom/qt-embedded-5.7 -debug -static -qt-zlib -qt-sql-sqlite2 -no-qml-debug -no-widgets -no-gui -no-opengl -openssl-linked -opensource -confirm-license -silent
? Что еще добавить/убавить? -embedded флаг в пятом вроде уже не действует (?)
На каком этапе нужно будет указать компилятор g++-arm-linux-gnueabihf? На этапе конфигурации или поздней?
Отредактированно: что вписать для опции -platform?
Итак был вопрос, что вписать для флага platform. Оказалось, что все «платформы» лежат в qtbase/mkspecs. Теперь яснен ответ на вопрос «где указать компилятор. Нашел там платформу близкую к нужной мне: linux-arm-gnueabi-g++. Это тоже что и linux-arm-gnueabihf-g++, но без поддрержки плавающих точек. Пошел на хак — скопировал linux-arm-gnueabi-g++ в linux-arm-gnueabihf-g++ и прописал в qmake.conf нужный мне (установленный у меня) компилятор:
Конфиг сработал, но тут новая бяда:
Из любопытства установил g++-arm-linux-gnueabi и выполнил с «легальной» платформой:
(об этом я говорил выше — g++-arm-linux-gnueabi не поддерживает плавающие точки, но даже «легальная» версия просто так не устанавливается
Кстати, нашел рекомендации примерно того, что делал я, но на практике не срабатывает из-за Syntax error: word unexpected (expecting «)») . Попробую покомбинировать флаги
И вот на этой ошибке я и застрял. Syntax error: word unexpected (expecting «)»)
Текущая конфигурация, которую пытаюсь запустить:
./configure -prefix /home/rishat/Qt-custom/qt-embedded-5.7 -debug -platform linux-arm-gnueabihf-g++ -qt-zlib -qt-sql-sqlite2 -no-qml-debug -no-widgets -no-gui -no-opengl -openssl-linked -opensource -confirm-license -v
Источник