Arm linux gnueabihf bin ld

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

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.

Источник

4.9 toolchain issue #50

Comments

solderspot commented Feb 19, 2016

I was able to cross compile my project successfully for Jessie using the previous gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf toolchain that was added briefly a few days ago. However, with the new replacement 4.9 toolchain arm-rpi-4.9.3-linux-gnueabihf I get this error when calling cmake:

Any suggestions as to what the problem is?

Here is the CMAKE_TOOLCHAIN_FILE that works fine for the previousgcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf toolchain, as well as gcc-linaro-arm-linux-gnueabihf-raspbian-x64:

[More details about the project can be found here: https://solderspot.wordpress.com/2016/02/04/cross-compiling-for-raspberry-pi-part-ii/]

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

popcornmix commented Feb 19, 2016

Does it help if you remove SET(CMAKE_SYSROOT $) ?

crt1.o lives in arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/sysroot/usr/lib with the new toolchain, but in gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf with the previous toolchain.

I’m not really sure why we are getting the difference, or which is the better option.

solderspot commented Feb 19, 2016

Yes, if I remove the sysroot setting then the cmake call works but the actual build (i.e. make) then fails as it cannot find the required header files:

I guess I could explicitly add all the system include paths to the FLAGS define for both the compilers and the linker but it would be nicer if things were more transparent. I would also worry that not using sysroot might potentially pull in host files?

carlonluca commented Feb 28, 2016

I’m experiencing many errors as well. For instance I’m getting:

In the old toolchain this is in:

and in the sysroot this is in:

but in the new toolchain this is in:

Maybe this change in the layout makes the compiler unable to find these headers? I notice a layout difference between the Raspbian sysroot and the new toolchain.
I’m stuck with the old one for the moment.

popcornmix commented Feb 28, 2016

If you find any .config options that make your builds work I’d be happy to include them (if they don’t break anything). With recent toolchain I can build linux kernel, the userland libs, kodi and omxplayer without issue.

carlonluca commented Feb 29, 2016

The older one works properly with the same makefiles, so maybe there is a difference in the configuration that explains the different layout?

solderspot commented Feb 29, 2016

It’s pretty easy to build the toolchain.

Is there a particular release of crosstool-ng that we should use?

As an aside: It would very helpful if there was some documentation (just a readme) that explained how this repo (raspberrypi/tools) is built and maintained, as well as list any important requirements for the toolchain. That way people like myself, with little or no crosstool-ng experience, can more easily help to trouble shoot and contribute. but maybe this toolchain is only meant for compiling the kernel and it is more appropriate to use other toolchain solutions for building applications? If so then stating that in a readme would be helpful too.

Anyway, I’m going to try building the toolchain like you say and report back if I learn anything useful.

popcornmix commented Feb 29, 2016

I was using latest master, which at the time was

bhundven commented Feb 29, 2016

@solderspot If you’re going to do a new build, I would try the latest master.

There have been some fixes to crosstool-ng since the release @popcornmix mentioned, but haven’t had time to look into this specific issue.

@carlonluca just brought this issue to my attention. I’m currently working on a few unrelated issues with crosstool-ng (Like, I just accidentally broke musl-libc support and am trying to fix that 😛 ).

As soon as I’m done fixing that, I will run some builds of my own to see if I can figure this out.

popcornmix commented Mar 1, 2016

@bhundven should it be possible to build gcc 5.3.0 with glibc 2.19?

I always get a build failure:

ClaymorePT commented Jun 1, 2016

I’m also having issues when using the rpi cross compiler v4.9.3.
The toolchain is unable to find the raspbian libraries in the root folder, into where I rsync the /lib and /usr folders.

Btw, the rpi compiler in tools, does not support multiarch.

`[claymore@claymore-laptop Boost]$ cd

/Raspbian/Tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/
[claymore@claymore-laptop arm-rpi-4.9.3-linux-gnueabihf]$ ls
arm-linux-gnueabihf bin include lib libexec share
[claymore@claymore-laptop arm-rpi-4.9.3-linux-gnueabihf]$ cd bin
[claymore@claymore-laptop bin]$ ls
arm-linux-gnueabihf-addr2line arm-linux-gnueabihf-c++filt arm-linux-gnueabihf-gcc arm-linux-gnueabihf-gcov arm-linux-gnueabihf-ldd arm-linux-gnueabihf-ranlib
arm-linux-gnueabihf-ar arm-linux-gnueabihf-cpp arm-linux-gnueabihf-gcc-4.9.3 arm-linux-gnueabihf-gdb arm-linux-gnueabihf-nm arm-linux-gnueabihf-readelf
arm-linux-gnueabihf-as arm-linux-gnueabihf-ct-ng.config arm-linux-gnueabihf-gcc-ar arm-linux-gnueabihf-gprof arm-linux-gnueabihf-objcopy arm-linux-gnueabihf-size
arm-linux-gnueabihf-c++ arm-linux-gnueabihf-elfedit arm-linux-gnueabihf-gcc-nm arm-linux-gnueabihf-ld arm-linux-gnueabihf-objdump arm-linux-gnueabihf-strings
arm-linux-gnueabihf-cc arm-linux-gnueabihf-g++ arm-linux-gnueabihf-gcc-ranlib arm-linux-gnueabihf-ld.bfd arm-linux-gnueabihf-populate arm-linux-gnueabihf-strip
[claymore@claymore-laptop bin]$ ./arm-linux-gnueabihf-g++ —print-multiarch

Mark-81 commented Jun 8, 2016 •

@carlonluca I’m facing the same problems about sys headers. I cannot use the old toolchain due to the ICU issue #41

it seems there is no working toolchain at the moment (at least for Qt5.6 and RPi3). Is there a way to fix one of them?

carlonluca commented Jun 8, 2016

@Mark-81 yes build icu with the old library. No more issues. Last time I tried 4.9 it was not working in the form provided so I can’t use it.

Mark-81 commented Jun 8, 2016

@carlonluca thanks! Have you tried with RPi3? Because gcc-linaro-arm-linux-gnueabihf-raspbian doesn’t like the architecture (armv8-a+crc) and the c++ flag (c++1z). I attach the qmake.conf file for rpi3 (linux-rpi3-g++).
qmake.txt

carlonluca commented Jun 8, 2016

@Mark-81 I use the same build conf that I use on Pi2. Maybe the toolchain is too old. Those params seems to be included in 4.9: https://gcc.gnu.org/gcc-4.9/changes.html.

ClaymorePT commented Jun 8, 2016 •

GCC 4.9 does not support most of the c++1z features. In fact, it doesn’t even support most of the C++14 features. :/
https://gcc.gnu.org/projects/cxx-status.html

On 8 June 2016 at 18:15, Luca Carlon notifications@github.com wrote:

@Mark-81 https://github.com/Mark-81 I use the same build conf that I
use on Pi2. Maybe the toolchain is too old. Those params seems to be
included in 4.9: https://gcc.gnu.org/gcc-4.9/changes.html.

Carlos Miguel Ferreira
Researcher at Telecommunications Institute
Aveiro — Portugal
Work E-mail — cmf@av.it.pt
Skype & GTalk -> carlosmf.pt@gmail.com
LinkedIn -> http://www.linkedin.com/in/carlosmferreira

thijstriemstra commented Jun 20, 2016

Running into this same annoying issue, the paths are different for each compiler, e.g.:

And apparently I need gcc 4.9 or my build fails with:

Here’s a diff between bcm2708-ct-ng.config and arm-rpi-4.9.3-linux-gnueabihf.config , e.g.:

These lines look suspicious but I’ve never used crosstool-ng. What’s x-tools6h-new and shouldn’t this be arm-bcm2708 ?

ali1234 commented Aug 21, 2016

Same problem as everyone else.

• gcc-linaro-arm-linux-gnueabihf-raspbian can’t link libicu from Raspbian Jessie because it is gcc 4.8 but Jessie is built with gcc 4.9
• arm-rpi-4.9.3-linux-gnueabihf does not work at all, and throws hundreds of errors on just about anything.
• gcc 4.9 direct from Linaro works fine. (https://releases.linaro.org/15.02/components/toolchain/binaries/arm-linux-gnueabihf/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf.tar.xz)

GrubbyHalo commented Sep 8, 2016

@ali1234 Thanks. gcc-4.9 from Linaro works flawlessly.

paresy commented Sep 26, 2016 •

The linaro toolchain was not able to produce valid binaries for RPi1.
After adding a lot of path information the new toolchain from this repository works.

make CC=»/home/user/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ —sysroot=/home/user/rpi-jessie/ -I/home/user/rpi-jessie/usr/include/arm-linux-gnueabihf/ -L/home/user/rpi-jessie/usr/lib/arm-linux-gnueabihf/ -B/home/user/rpi-jessie/usr/lib/arm-linux-gnueabihf/»

grheard commented Oct 2, 2016

@paresy, I’m glad you were able to get the repo’s rpi-4.9.3 compiler to work for you, but for me its still a no go on the pi zero.

Surely the raspbian guys cross compiled jessie from source. Jessie works fine on the pi zero. Where is that toolchain? I really don’t want to compile on the target.

thijstriemstra commented Oct 2, 2016

grheard commented Oct 2, 2016

@thijstriemstra, doesn’t work too well with jessie as the sysroot:

/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to pthread_setspecific@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_attr_setstacksize@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlerror@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to pthread_key_create@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_join@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_post@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to sem_trywait@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlclose@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to pthread_getspecific@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_init@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_wait@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_mutexattr_init@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_getvalue@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_destroy@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlopen@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_mutexattr_settype@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_once@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_mutexattr_destroy@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlsym@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_create@GLIBC_2.4′
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to pthread_key_delete@GLIBC_2.4′ /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to clock_gettime@GLIBC_2.4′

grheard commented Oct 3, 2016 •

Well damn. I owe @thijstriemstra and @paresy an apology.

Seems I missed a couple of very important error messages:

/home/heardg/pi/linaro/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4/../../../../arm-linux-gnueabihf/bin/ld: warning: libpthread.so.0, needed by /home/heardg/pi/system/devroot/opt/vc/lib/libGLESv2.so, not found (try using -rpath or -rpath-link) /home/heardg/pi/linaro/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4/../../../../arm-linux-gnueabihf/bin/ld: warning: libdl.so.2, needed by /home/heardg/pi/system/devroot/opt/vc/lib/libGLESv2.so, not found (try using -rpath or -rpath-link) /home/heardg/pi/linaro/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4/../../../../arm-linux-gnueabihf/bin/ld: warning: librt.so.1, needed by /home/heardg/pi/system/devroot/opt/vc/lib/libGLESv2.so, not found (try using -rpath or -rpath-link)

I will admit I don’t know enough about compilers or even gcc to understand what’s changed, but with Linaro’s 4.9-2016.02 compiler I need to add -lpthread -ldl -lrt to the linker invocation and now things are linking again.

I will report back when I get things fixed up enough to link against icu to make sure everything works.

Edit 2016-10-03: The above linked compiler works with the pi zero/pi 1 and the jessie image as the sysroot.

Sorry for the clutter and confusion I may have caused.

jyhakala commented Oct 10, 2016 •

Hi,
What about 23-09-2016 Jessie with Raspberry Pi 3. Does that toolchain work? Or do I need to install it from Linaro? If using host Ubuntu 16.04 LTS, what kind of configuration should I use?

xbomber commented Nov 12, 2016 •

I found a solution for arm-rpi-4.9.3-linux-gnueabihf.

• I modified qtbase/mkspecs/devices/linux-rasp-pi-g++/qmake.conf
  adding this lines just afeter first include:

This lines fix some path not found.

• I renamed tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++
  in tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++.real,
• I created a script named tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ containing this code:

This script copy crti.o and crt1.o in build directory off all’ compiling project and after call real g++. This solve link errors.
Typed chmod 755 to this script.

• I created the following script for comodity in qtbase:

You have only to change locations /home/marco in your locations.
Now I have a cross compiling system built with g++4.9.3 and c++11 included.

Источник