Arm linux gnueabihf libraries

Arch Linux User Repository

Search Criteria

Package Details: arm-linux-gnueabihf-glibc 2.33-3

Package Actions

Git Clone URL:	https://aur.archlinux.org/arm-linux-gnueabihf-glibc.git (read-only, click to copy)
Package Base:	arm-linux-gnueabihf-glibc
Description:	GNU C Library (arm-linux-gnueabihf)
Upstream URL:	https://www.gnu.org/software/libc/
Licenses:	GPL, LGPL
Conflicts:	arm-linux-gnueabihf-eglibc, arm-linux-gnueabihf-glibc-headers
Provides:	arm-linux-gnueabihf-eglibc, arm-linux-gnueabihf-glibc-headers=2.33
Replaces:	arm-linux-gnueabihf-glibc-headers
Submitter:	tavianator
Maintainer:	razykov
Last Packager:	razykov
Votes:	35
Popularity:	0.005061
First Submitted:	2015-09-14 15:40
Last Updated:	2021-05-29 16:41

Dependencies (4)

• arm-linux-gnueabihf-linux-api-headers>=5.10.9-2 (arm-linux-gnueabihf-android-linux-api-headers)
• gperf (gperf-git) (make)
• python (python-dbg, python35, python38, python36, python310, python311, python37) (make)
• arm-linux-gnueabihf-gcc-stage2>=11.1.0-1 (arm-linux-gnueabihf-gcc) (make)

Required by (4)

• arm-linux-gnueabihf-gcc
• arm-linux-gnueabihf-gcc-stage2 (requires arm-linux-gnueabihf-glibc-headers)
• arm-linux-gnueabihf-ncurses
• darling-bin

Sources (5)

Latest Comments

razykov commented on 2021-10-04 18:05

Yep. I prepared patch for update PKGBUILD to 2.34. It build the package and compile a ‘hello world’ but I ran into a problem ( version ‘GLIBC_2.34’ not found ) when starting the program on RspberryOS (glibc 2.28 ) and ArchlinuxARM (glibc 2.33 ). Now I uploaded patch on my github (https://github.com/razykov/arm-linux-gnueabihf-glibc). If you have any ideas let me know

fabian-ang commented on 2021-10-04 12:32

Is there any specific reason you don’t update glibc?

staletic commented on 2021-06-02 05:38

Can’t be compiled with the lto option enabled. At least when compiled with stage 2 gcc.

gkatev commented on 2020-09-07 12:08

Thought I would/should mention I came across a problem when compiling this. Specifically:

Should the sdt header already be present in the toolchain? I was upgrading from 2.28-5, and, at the time, arm-linux-gnueabihf-gcc was version 8.2.1+20181127-1. Maybe the slightly outdated compiler was the reason (?).

I copied the bundled std-config.h and sdt.h to /usr/arm-linux-gnueabihf/include/sys , and the package compiled successfully. (And installed it manually with pacman —overwrite)

xiretza commented on 2020-05-18 17:08

@tavianator: ah, you’re right! Confirmation bias got the better of me, I was convinced it was DEBUG_CFLAGS that were added, not just the -fdebug-prefix-map . In fact DEBUG_CFLAGS is unset just like CFLAGS by !buildflags , but that extra option is then added in /usr/share/makepkg/buildenv/debugflags.sh regardless of the build flags. In that case, yes, just adding -g -O2 is probably the way to go.

tavianator commented on 2020-05-18 15:57

@xiretza: Interesting. This package needs !buildflags to avoid things like -march=x86-64 . But actually with !buildflags , the DEBUG_CFLAGS don’t get passed either. However, makepkg does add -fdebug-prefix-map=$srcdir=/usr/src/debug to CFLAGS , which causes the problem you describe. Therefore I think the best thing to do is to pass the default flags -g -O2 explicitly.

xiretza commented on 2020-05-18 14:50

Hey! First of all, thanks for packaging, toolchains are always a pain. Unfortunately, this package can’t be built with OPTIONS=(debug) set in makepkg.conf:

By default (without debug ), CFLAGS is empty/unset thanks to !buildflags . This causes glibc to fall back to a default set of flags, -g -O2 (see Makeconfig:327 ).

Now, when debug is set, DEBUG_CFLAGS from makepkg.conf get appended to CFLAGS . This happens after !buildflags unsets the variables, which has been determined to be intentional/notabug after bringing it up in #archlinux-pacman. With CFLAGS now set to -g -fvar-tracking-assignments , the glibc build system no longer falls back to its defaults, and since there’s no -Ox option set, the build fails (I have not found an explanation why glibc needs optimizations to be on, so that’s just how it is).

There are a couple possible solutions for this, but I think the safest way is to follow the example of official PKGBUILDS. The riscv64-linux-gnu-glibc PKGBUILD for example always sets CFLAGS to a fixed value — while this fixes the problem, it’s not ideal because it discards the extra flags added from DEBUG_CFLAGS . I think the best solution would be this:

In the normal, non-debug case this behaves exactly the same as the riscv64 glibc (and almost the same as before the change, except no -g being passed by default), and with debug , the debug flags are added while still keeping optimization on and hardening disabled.

tavianator commented on 2019-02-05 01:46

@skogsmaskin: You’ll have to build that package first (and its dependencies before it, etc.). Check the pinned post on https://aur.archlinux.org/packages/arm-linux-gnueabihf-gcc/ for the correct order.

skogsmaskin commented on 2019-02-03 13:41

Getting this error from the lastest update:

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 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.23
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

xzz53 commented on 2021-10-08 21:01

isl.gforge.inria.fr seems to be gone for good, so can’t download isl-0.24.tar.xz needed for this recipe. It’s now available via [1]. More details: [2].

aguegu commented on 2021-07-08 11:08

if building failed, try to add these two lines to PKGBUILD.

felipebalbi commented on 2021-06-30 09:21

Getting unknown key when trying to install stage1.

UPDATE: manually importing the key worked fine

smallAndSimple commented on 2021-06-05 11:52

Every single time an update comes out for this package, I need to install stage-1 -> stage-2 -> this. Is it possible to update directly without having to reinstall stage-1 and stage-2 every single time?

Edit: the problem is arm-linux-gnueabihf-glibc, which requires a newer gcc, but the newer gcc requires the newer glibc. Only way to break the cycle is to install the new stage-2, which requires the new stage-1.

mtudan commented on 2021-03-17 09:35

Got the following error with paru :

JanSurft commented on 2021-03-05 13:55

Is there a straight forward way to also provide the libstdc++.a static library together with the shared?

I can only see the *.so files of libstdc++ and I would need the static one for some cross compilation issues.

@smallAndSimple: it worked perfectly the way you described it

smallAndSimple commented on 2021-02-20 15:09

Edit: this is about the missing libctf problem.

I digged around a bit, and the actual problem lies in arm-linux-gnueabihf-binutils. I did the following as a workaround:

Cleaned up all arm-linux-gnueabihf-* related stuff completely.

Download arm-linux-gnueabihf-binutils PKGBUILD and add —disable-libctf\ to the list of ./configure parameters

makepkg -sri to install arm-linux-gnueabihf-binutils

A less thorough approach might be possible. Also, libctf apparantly can do something useful with debug sections, so you might run into trouble down the line.

smallAndSimple commented on 2021-02-20 14:37

So, since the libctf.so.0 situation will probably not be solved very soon (https://bugs.archlinux.org/task/69567 is closed because of upstream), is there a way around it? Can you compile this without libctf?

CapSel commented on 2021-02-18 11:13

Can’t compile. libctf.so.0 is missing. Here is bug for it https://bugs.archlinux.org/task/69567

tayspen72 commented on 2021-01-31 18:56

@AchmadFathoni My mistake. I pasted them in the wrong order. It should be stage 1 -> stage 2 -> gcc. I called them progressive because stage 1 is used to build stage 2, stage 2 is used to build the final gcc.

Copyright © 2004-2021 aurweb Development Team.

AUR packages are user produced content. Any use of the provided files is at your own risk.

Источник

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

Источник