Arm unknown linux gnueabihf

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

Достаточно давно хотел освоить сабж, но всё были другие более приоритетные дела. И вот настала очередь кросскомпиляции.

В данном посте будут описаны:

1. Инструменты
2. Элементарная технология кросскомпиляции
3. И, собственно, 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.

Источник

unable to execute ‘arm-linux-gnueabihf-gcc’: No such file or directory #42

Comments

RooHoo33 commented Oct 27, 2016

I run sudo python setup.py install and it comes back with the error unable to execute ‘arm-linux-gnueabihf-gcc’: No such file or directory`
Here is the full log: SteamController.txt

I am using a raspberry pi 3
Thanks

The text was updated successfully, but these errors were encountered:

ynsta commented Nov 2, 2016

I think you should install gcc-multilib.

On Fri, Oct 28, 2016 at 12:35 AM, RooHoo33 notifications@github.com wrote:

I run sudo python setup.py installand it comes back with the errorunable
to execute ‘arm-linux-gnueabihf-gcc’: No such file or directory`
Here is the full log: SteamController.txt
https://github.com/ynsta/steamcontroller/files/557174/SteamController.txt

I am using a raspberry pi 3
Thanks

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#42, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB26C8lBW6NQCv0PpyBbP9FTb7xb8lQGks5q4Sc5gaJpZM4Ki5eD
.

RooHoo33 commented Nov 2, 2016

When I type sudo apt-get install gcc-multilib to install it I get Package ‘gcc-multilib’ has no installation candidate

waspbr commented Nov 26, 2016 •

I have the same issue with the Pie 3 running retropie. Apparently gcc-multilib is not in the repos.

Edit: The script seems to run well with python3

sudo python3 setup.py install

btyock commented Jan 3, 2017

I am also getting an error with arm-linux-gnueabihf-gcc as well as a few other things. I tried installing gcc-multilib and running it with python3 and neither are working.

Источник

Cross compiling for ARM #274

Comments

happybeing commented Jun 19, 2015

I’m building the maidsafe (Rust) code on an Intel Debian machine, and cross compiling for ARM (arm-unknown-linux-gnueabihf). I have the Rust code cross compiling fine, and «file» reports the output is ARM. I get all the way to linking the maidsafe code, but it fails at that point because I don’t have an ARM build of libsodium.

I can build everything for the intel Debian machine.

I’ve tried several things but can’t get libsodium to build for ARM. It happily compiles without error, but always the output is x86 (as reported by «file»).

I’ve looked at the GNU autoconfigure code and in the libsodium scripts but don’t understand what I’m doing wrong. Here’s one example:

./configure —build=x86_64-unknown-linux-gnu —host=arm-unknown-linux-gnueabihf —target=arm-unknown-linux-gnueabihf

The Makefile has the host_triplet etc set correctly, but «make V=1» shows the compiler is not being told to build for ARM architecture. For example:

/bin/bash ../../libtool —tag=CC —mode=compile gcc -std=gnu99 -DPACKAGE_NAME=»libsodium» -DPACKAGE_TARNAME=»libsodium» -DPACKAGE_VERSION=»1.0.3″ -DPACKAGE_STRING=»libsodium\ 1.0.3″ -DPACKAGE_BUGREPORT=»https://github.com/jedisct1/libsodium/issues\» -DPACKAGE_URL=»https://github.com/jedisct1/libsodium\» -DPACKAGE=»libsodium» -DVERSION=»1.0.3″ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=».libs/» -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DHAVE_WEAK_SYMBOLS=1 -DCPU_ALIGNED_ACCESS_REQUIRED=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_POSIX_MEMALIGN=1 -I. -I../../../../src/libsodium -I../../../../src/libsodium/include/sodium -I./include/sodium -D_FORTIFY_SOURCE=2 -g -O2 -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -Winit-self -Wwrite-strings -Wdiv-by-zero -MT crypto_aead/chacha20poly1305/sodium/libsodium_la-aead_chacha20poly1305.lo -MD -MP -MF crypto_aead/chacha20poly1305/sodium/.deps/libsodium_la-aead_chacha20poly1305.Tpo -c -o crypto_aead/chacha20poly1305/sodium/libsodium_la-aead_chacha20poly1305.lo test -f ‘crypto_aead/chacha20poly1305/sodium/aead_chacha20poly1305.c’ || echo ‘../../../../src/libsodium/’ crypto_aead/chacha20poly1305/sodium/aead_chacha20poly1305.c

The only clue I have is that configure reports the following warning (here I’m trying a different arm architecture, but the results are the same for arm-unknown-linux-gnueabihf, which is what I’m really trying to build.

$ ./configure —build=x86_64-unknown-linux-gnu —host=arm-none-eabi —target=arm-none-eabi

checking build system type. x86_64-unknown-linux-gnu
checking host system type. arm-none-eabi
checking for a BSD-compatible install. /usr/bin/install -c
checking whether build environment is sane. yes
checking for arm-none-eabi-strip. no
checking for strip. strip
configure: WARNING: using cross tools not prefixed with host triplet

It may well not be a libsodium issue, but I can’t understand why it is accepting the architecture but ignoring it without error. Any clues?

The text was updated successfully, but these errors were encountered:

Источник