Package Details: arm-linux-gnueabihf-gcc 11.2.0-3

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, arm-linux-gnueabihf-gcc-stage2
Replaces: arm-linux-gnueabihf-gcc-stage1, arm-linux-gnueabihf-gcc-stage2
Submitter: tavianator
Maintainer: razykov
Last Packager: razykov
Votes: 77
Popularity: 0.091340
First Submitted: 2015-09-14 15:41 (UTC)
Last Updated: 2021-10-13 01:11 (UTC)

Latest Comments

killruana commented on 2022-05-03 18:01 (UTC) (edited on 2022-05-03 18:02 (UTC) by killruana)

Hi AUR user!

You tried to install this package and get some errors? me too :)

To summarize what it said below, you need to install arm-linux-gnueabihf-gcc-stage1, then arm-linux-gnueabihf-gcc-stage2 and finally arm-linux-gnueabihf-gcc [1].

You also need the edit the PKGBUILD of the thee package to add theses lines at the begin of the build functions [2]:

    CFLAGS="${CFLAGS/ -Werror=format-security/}" 
    CXXFLAGS="${CXXFLAGS/ -Werror=format-security/}"

E.G.:

$ paru -S --fm nvim arm-linux-gnueabihf-gcc-stage1
$ paru -S --fm nvim arm-linux-gnueabihf-gcc-stage2
$ paru -S --fm nvim arm-linux-gnueabihf-gcc

1: https://aur.archlinux.org/packages/arm-linux-gnueabihf-gcc#comment-788911 2: https://aur.archlinux.org/packages/arm-linux-gnueabihf-gcc#comment-816423

xzz53 commented on 2021-10-08 21:01 (UTC) (edited on 2021-10-08 21:02 (UTC) by xzz53)

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

[1] https://libisl.sourceforge.io/isl-0.24.tar.xz

[2] https://groups.google.com/g/isl-development/c/JGaMo2VUu_8

aguegu commented on 2021-07-08 11:08 (UTC)

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

CFLAGS="${CFLAGS/ -Werror=format-security/}" CXXFLAGS="${CXXFLAGS/ -Werror=format-security/}"

https://aur.archlinux.org/packages/arm-linux-gnueabihf-gcc-stage1/#comment-811696

felipebalbi commented on 2021-06-30 09:21 (UTC) (edited on 2021-06-30 09:30 (UTC) by felipebalbi)

Getting unknown key when trying to install stage1.

UPDATE: manually importing the key worked fine

smallAndSimple commented on 2021-06-05 11:52 (UTC) (edited on 2021-06-05 11:55 (UTC) by smallAndSimple)

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 (UTC)

Got the following error with paru:

configure: error: 
*** These critical programs are missing or too old: GNU ld
*** Check the INSTALL file for required versions.

JanSurft commented on 2021-03-05 13:55 (UTC) (edited on 2021-03-05 13:55 (UTC) by JanSurft)

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 (UTC) (edited on 2021-02-20 15:17 (UTC) by smallAndSimple)

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:

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

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

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

  4. Install arm-linux-gnueabihf-gcc-stage1

  5. Install arm-linux-gnueabihf-gcc-stage2

  6. Install this

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 (UTC)

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 (UTC)

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 (UTC)

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

AchmadFathoni commented on 2021-01-30 23:38 (UTC)

@tayspen72 Are you sure that sequence correct? Becasue arm-linux-gnueabihf-gcc-stage2 requires arm-linux-gnueabihf-glibc-headers which requires arm-linux-gnueabihf-gcc-stage1. I get this error when installing arm-linux-gnueabihf-gcc-stage2

==> Missing dependencies:
  -> arm-linux-gnueabihf-gcc-stage1>=10.2.0-1
==> ERROR: Could not resolve all dependencies.
error making: arm-linux-gnueabihf-glibc-headers

tayspen72 commented on 2021-01-30 16:41 (UTC) (edited on 2021-01-31 18:54 (UTC) by tayspen72)

@AchmadFathoni remember that this cross-compile gcc is a progressive or sequential install. They must be installed in order. IE:

-> arm-linux-gnueabihf-gcc-stage1
-> arm-linux-gnueabihf-gcc-stage2
-> arm-linux-gnueabihf-gcc

I just verified this, also using yay.

AchmadFathoni commented on 2021-01-30 15:54 (UTC) (edited on 2021-01-30 16:30 (UTC) by AchmadFathoni)

Yay error

==> Missing dependencies:
  -> arm-linux-gnueabihf-gcc-stage2>=10.2.0-1
==> ERROR: Could not resolve all dependencies.
error making: arm-linux-gnueabihf-glibc

Is there any AUR helper beside yay that can successfully install this package?

tavianator commented on 2021-01-19 14:50 (UTC)

My Raspberry Pi died, so I don't have the ability to test this package any more. If anyone wants to take over maintenance please be my guest!

lightning1141 commented on 2021-01-15 09:27 (UTC)

Please change source url to use a mirror.

yshui commented on 2021-01-04 10:34 (UTC)

Can you install libatomic in package()?

wojciechkepka commented on 2020-10-04 05:01 (UTC) (edited on 2020-10-04 05:02 (UTC) by wojciechkepka)

I also had a problem importing GPG keys, but changing the keyserver to pool.sks-keyservers.net helped import them manually. But now i'm getting this:

==> Verifying source file signatures with gpg...
    gcc-10.1.0.tar.xz ... Passed (WARNING: the key has expired.)
==> WARNING: Warnings have occurred while verifying the signatures.
    Please make sure you really trust them.
 -> arm-linux-gnueabihf-gcc-stage2 not satisfied, flushing install queue
==> Making package: arm-linux-gnueabihf-glibc 2.31-3.1 (Sun 04 Oct 2020 06:59:25 AM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Missing dependencies:
  -> arm-linux-gnueabihf-gcc-stage2
==> ERROR: Could not resolve all dependencies.
error making: arm-linux-gnueabihf-glibc

peter.babic commented on 2020-09-09 05:01 (UTC)

gpg --keyserver pool.sks-keyservers.net --recv-keys ABAF11C65A2970B130ABE3C479BE3E4300411886 BC7C7372637EC10C57D7AA6579C43DFBF1CF2187 F3691687D867B81B51CE07D9BBE43771487328A9 13975A70E63C361C73AE69EF6EEB81F8981C74C7 33C235A34C46AA3FFB293709A328C3A2C3C45C06 3A24BC1E8FB409FA9F14371813FCEF89DD9E3C4F 647F28654894E3BD457199BE38DBBDC86092693E 7273542B39962DF7B299931416792B4EA25340F8 86CFFCA918CF3AF47147588051E8B148A9999C34

DocMAX commented on 2020-08-26 14:50 (UTC)

Fixed that... now:

==> Verifying source file signatures with gpg... gcc-10.1.0.tar.xz ... Passed -> arm-linux-gnueabihf-gcc-stage2 not satisfied, flushing install queue ==> Making package: arm-linux-gnueabihf-glibc 2.31-3.1 (Wed Aug 26 16:49:47 2020) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Missing dependencies: -> arm-linux-gnueabihf-gcc-stage2 ==> ERROR: Could not resolve all dependencies. error making: arm-linux-gnueabihf-glibc

DocMAX commented on 2020-08-26 13:20 (UTC)

Getting an error:

:: PGP keys need importing: -> 3A24BC1E8FB409FA9F14371813FCEF89DD9E3C4F, required by: arm-linux-gnueabihf-binutils -> 7273542B39962DF7B299931416792B4EA25340F8, required by: arm-linux-gnueabihf-glibc -> BC7C7372637EC10C57D7AA6579C43DFBF1CF2187, required by: arm-linux-gnueabihf-glibc -> F3691687D867B81B51CE07D9BBE43771487328A9, required by: arm-linux-gnueabihf-gcc -> 86CFFCA918CF3AF47147588051E8B148A9999C34, required by: arm-linux-gnueabihf-gcc -> 13975A70E63C361C73AE69EF6EEB81F8981C74C7, required by: arm-linux-gnueabihf-gcc -> 33C235A34C46AA3FFB293709A328C3A2C3C45C06, required by: arm-linux-gnueabihf-gcc :: Importing keys with gpg... gpg: keyserver receive failed: General error problem importing keys

alzeha commented on 2020-06-27 09:55 (UTC) (edited on 2020-06-27 09:55 (UTC) by alzeha)

@tavianator

Sorry for the late reply. I am usually busy from Monday to Friday :/

Yes, I do:

[alzeha@flaptop ~]$ ls /usr/arm-linux-gnueabihf/lib/
audit                    libdl.so.2             libpthread.a
crt1.o                   libg.a                 libpthread.so
crti.o                   libgcc_s.so            libpthread.so.0
crtn.o                   libgcc_s.so.1          libresolv-2.31.so
gconv                    libm-2.31.so           libresolv.a
gcrt1.o                  libm.a                 libresolv.so
ld-2.31.so               libmcheck.a            libresolv.so.2
ld-linux-armhf.so.3      libmemusage.so         librt-2.31.so
ldscripts                libm.so                librt.a
libanl-2.31.so           libm.so.6              librt.so
libanl.a                 libnsl-2.31.so         librt.so.1
libanl.so                libnsl.so.1            libSegFault.so
libanl.so.1              libnss_compat-2.31.so  libstdc++fs.a
libBrokenLocale-2.31.so  libnss_compat.so       libstdc++.so
libBrokenLocale.a        libnss_compat.so.2     libstdc++.so.6
libBrokenLocale.so       libnss_db-2.31.so      libstdc++.so.6.0.28
libBrokenLocale.so.1     libnss_db.so           libstdc++.so.6.0.28-gdb.py
libc-2.31.so             libnss_db.so.2         libsupc++.a
libc.a                   libnss_dns-2.31.so     libthread_db-1.0.so
libc_nonshared.a         libnss_dns.so          libthread_db.so
libcrypt-2.31.so         libnss_dns.so.2        libthread_db.so.1
libcrypt.a               libnss_files-2.31.so   libutil-2.31.so
libcrypt.so              libnss_files.so        libutil.a
libcrypt.so.1            libnss_files.so.2      libutil.so
libc.so                  libnss_hesiod-2.31.so  libutil.so.1
libc.so.6                libnss_hesiod.so       Mcrt1.o
libdl-2.31.so            libnss_hesiod.so.2     Scrt1.o
libdl.a                  libpcprofile.so
libdl.so                 libpthread-2.31.so
[alzeha@flaptop ~]$ 

tavianator commented on 2020-06-23 16:53 (UTC)

@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 (UTC) (edited on 2020-06-27 09:55 (UTC) by alzeha)

Hi,

does anyone else have something like this:

arm-linux-gnueabihf-gcc -O2 -Wall -Wextra -std=c99 -Iinc -I. -L. tst/test_loragw_spi.c -o test_loragw_spi -lloragw -lrt -lm
/usr/bin/arm-linux-gnueabihf-ld: warning: libpthread.so.0, needed by /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so, not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `pthread_detach@GLIBC_2.4'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `__pthread_barrier_wait@GLIBC_PRIVATE'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `__pthread_barrier_init@GLIBC_PRIVATE'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `pthread_create@GLIBC_2.4'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `__pthread_unwind@GLIBC_PRIVATE'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `pthread_attr_setstacksize@GLIBC_2.4'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `pthread_cancel@GLIBC_2.4'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `pthread_sigmask@GLIBC_2.4'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `pthread_once@GLIBC_2.4'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `__shm_directory@GLIBC_PRIVATE'
/usr/bin/arm-linux-gnueabihf-ld: /usr/lib/gcc/arm-linux-gnueabihf/10.1.0/../../../../arm-linux-gnueabihf/lib/librt.so: undefined reference to `__pthread_get_minstack@GLIBC_PRIVATE'

I do not see, what is happening here. I followed the order, given at the pinned comment.

EDIT:

[alzeha@flaptop ~]$ /usr/bin/arm-linux-gnueabihf-ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("/usr/lib/binutils/arm-linux-gnueabihf")
SEARCH_DIR("=/usr/arm-linux-gnueabihf/lib")

This does not seem right, or? There is additional =?

tavianator commented on 2020-06-10 20:50 (UTC)

@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 (UTC)

@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

https://ibb.co/phRmbbf https://ibb.co/2sDWDHj

tavianator commented on 2020-06-10 20:33 (UTC)

@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 (UTC) (edited on 2020-05-30 21:11 (UTC) by volker.raschek)

Failed to build the package with yay. Missing dependency arm-linux-gnueabihf-gcc-stage2.

(2/2) Keep the last cache and the currently installed.
==> no candidate packages found for pruning
==> Erstelle Paket: arm-linux-gnueabihf-glibc 2.31-3.1 (Sa 30 Mai 2020 23:07:56 CEST)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Prüfe Buildtime-Abhängigkeiten...
==> Fehlende Abhängigkeiten:
  -> arm-linux-gnueabihf-gcc-stage2
==> FEHLER: Konnte nicht alle Abhängigkeiten auflösen.
Error making: arm-linux-gnueabihf-glibc

Can anybody fix the error?

streblo commented on 2020-05-28 21:25 (UTC)

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 (UTC)

@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 (UTC)

@tavianator the reason I went with 10.1 is twofold:

  1. AARCH64 is already in 10.1 (see https://www.archlinux.org/packages/community/x86_64/aarch64-linux-gnu-gcc/)

  2. 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:

  1. https://github.com/felipebalbi/arm-linux-gnueabihf-binutils/commit/a9155a826e5516629e95037cb43b384c7a30bfdb
  2. https://github.com/felipebalbi/arm-linux-gnueabihf-gcc-stage1/commit/ed06b071689303dcc310fefb5a4d23826c789970
  3. https://github.com/felipebalbi/arm-linux-gnueabihf-linux-api-headers/commit/0e0d710aeefdff4bc3f3ff82dae4d34142c4ce4b
  4. https://github.com/felipebalbi/arm-linux-gnueabihf-glibc-headers/commit/e828eb4bacbc428b820a27b20fb445a160dcd018
  5. https://github.com/felipebalbi/arm-linux-gnueabihf-gcc-stage2/commit/a505dd9d25f119548501b76105fa614ea47e7e41
  6. https://github.com/felipebalbi/arm-linux-gnueabihf-glibc/commit/2e67b8513ee0f4463f76a11b8b90c51228893f38
  7. https://github.com/felipebalbi/arm-linux-gnueabihf-gcc/commit/2bbb16d1545b54e845652c400ef3ea67878b869b

cheers

tavianator commented on 2020-05-13 01:55 (UTC)

@felipebalbi Sure, post the patches somewhere and I'll at least take a look.

Generally I try to follow the non-cross versions of these packages, which means taking changes from https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/gcc and friends. Since Arch isn't at 10.1 yet, neither is this package.

felipebalbi commented on 2020-05-12 06:19 (UTC) (edited on 2020-05-12 14:23 (UTC) by felipebalbi)

Would you accept a patch updating GCC to 10.1 or is someone already working on that? Also, assuming you would accept such a patch, would it require updating binutils and glibc as well?

UPDATE: FYI, I have the patch for gcc and I've tested it by building the linux-kernel.

UPDATE 2: I wrote the patches for all other packages (binutils, gcc-stage1, linux-api-headers, glibc-headers, gcc-stage2 and glibc), however binutils won't install due to it trying to overwrite existing files. I'll try to figure out why those files are included. Once all packages are compiling and installing fine, I'll report here.

UPDATE 3: All 7 packages built and installed. Working fine so far. It would be great to have them integrated so we can all have newest GCC for ARM32 boards

acxz commented on 2020-03-21 23:06 (UTC)

@tavianator or anyone else, I have a question. I am trying to find the equivalent of the ubuntu package pkg-config-arm-linux-gnueabihf on ArchLinux. Which package should I look for?

smallAndSimple commented on 2020-01-12 15:01 (UTC)

Yes, that worked. Thank you!

tavianator commented on 2020-01-10 15:32 (UTC)

@smallAndSimple: I pushed an update to alg-glibc that removes the version requirement on gcc. That should allow everything to build automatically, let me know if it works.

smallAndSimple commented on 2020-01-10 10:48 (UTC)

I cannot update this packet in Yay because of a weird (curcular?) thing:

I want to update arm-linux-gnueabihf-gcc to 9.2.0-4. But for that I need arm-linux-gnueabihf-glibc 2.30-3. To install linux-gnueabihf-glibc, I will need arm-linux-gnueabihf-gcc-stage2>=9.2.0-4, which arm-linux-gnueabihf-gcc does provide, but I cannot install that because of the glibc version.

How can I break this cycle, other than removing all of the arm-linux-gnueabihf packagesd and reinstalling them in order?

mikro commented on 2019-05-22 15:00 (UTC)

There is no need to mess with any order, just install arm-linux-gnueabihf-gcc and arm-linux-gnueabihf-glibc together.

However I'm getting a failure anyway, see my comment here: https://aur.archlinux.org/packages/arm-linux-gnueabihf-glibc-headers/#comment-694530

tavianator commented on 2019-02-05 01:45 (UTC)

@TheSaint: Uh because that's how you build a cross-toolchain? If you have a better way please let me know! I think it's possible to do 2 stages of GCC instead of 3 but I haven't gotten it working. At least my install.sh script should avoid wasting bandwidth, as it symlinks the glibc and gcc tarballs to avoid re-downloading them.

TheSaint commented on 2019-02-04 01:42 (UTC) (edited on 2019-02-04 02:00 (UTC) by TheSaint)

Today I got an update, but there's no order that the aur helper will respect. I currently using pikaur. So I presume that the entire update should be packaged with one only script as you mentioned, which is presumably the install.sh I followed your proposed order, but still have to discard a package because of conflicts. gcc-stage2 discards gcc-stage1 glibc discards glibc-headers gcc discards gcc-stage2

Why should we bear for such bandwidth & time wastage ?

crazySocket commented on 2019-01-27 15:04 (UTC) (edited on 2019-01-27 15:05 (UTC) by crazySocket)

Package as is does not allow for -static flag for gcc. If you try you get error "/usr/bin/arm-linux-gnueabihf-ld: cannot find -lstdc++".

The solution is to build libstdc++.a yourself. I had to inspect PKGBUILD for source url, compile as described there http://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter05/gcc-libstdc++.html, then move libstdc++.a into /usr/arm-linux-gnueabihf. What could be avoided if only both shared and static version of stdlib were build by default.

I think package should have libstdc++.a included. At least I would appreciate that.

tavianator commented on 2018-08-15 15:55 (UTC) (edited on 2018-08-15 15:56 (UTC) by tavianator)

@TheSaint: The correct order can be seen here: https://github.com/tavianator/arch-rpi-cross/blob/master/install.sh

It is

arm-linux-gnueabihf-binutils
arm-linux-gnueabihf-gcc-stage1
arm-linux-gnueabihf-linux-api-headers
arm-linux-gnueabihf-glibc-headers
arm-linux-gnueabihf-gcc-stage2
arm-linux-gnueabihf-glibc
arm-linux-gnueabihf-gcc

The dependencies and provides have been set up so that AUR helpers should (hopefully) figure that out automatically.

TheSaint commented on 2018-08-15 15:49 (UTC)

To compile this package is necessary arm-linux-gnueabihf-binutils, which require arm-linux-gnueabihf-gcc-stage2. But also the arm-linux-gnueabihf-linux-api-headers is in the dependencies list, which require arm-linux-gnueabihf-gcc-stage1, but then there's a conflict with arm-linux-gnueabihf-gcc-stage2. Then also arm-linux-gnueabihf-glibc-headers are in conflict with arm-linux-gnueabihf-glibc. So what is the right one and save us to download the wrong one ?

zerofrost commented on 2018-06-27 14:39 (UTC)

For anyone having public key issues, I had to do gpg --recv-keys 16792B4EA25340F8

loadlover commented on 2018-02-09 17:45 (UTC)

Please ignore my previous comment as I have solved the issue (undeclared env variables) by removing C/C++ entries in my .bashrc.

loadlover commented on 2018-02-09 15:17 (UTC)

I'm getting the following errors. Can anyone help pls? I'm not very experienced at this..

error: ‘DEFAULT_GENERATE_ELF_STT_COMMON’ undeclared here (not in a function); did you mean ‘BFD_USE_ELF_STT_COMMON’? error: ‘TARGET_ALIAS’ undeclared (first use in this function); did you mean ‘TARGET_ARCH’? error: ‘TARGET_ALIAS’ undeclared (first use in this function); did you mean ‘TARGET_ARCH’? error: ‘TARGET_CANONICAL’ undeclared (first use in this function); did you mean ‘TARGET_ALIAS’? error: ‘TARGET_CPU’ undeclared (first use in this function); did you mean ‘TARGET_ARCH’?

patrickelectric commented on 2018-02-06 15:00 (UTC)

Why this package does not come with arm-linux-gnueabihf-pkg-config ?

Glavnokoman commented on 2018-01-25 12:43 (UTC)

fixed by reinstalling arm-linux-gnueabihf-binutils

Glavnokoman commented on 2018-01-25 10:33 (UTC)

after update to 7.2.0-3 compilation of trivial main.c fails with '/usr/lib/gcc/arm-linux-gnueabihf/7.2.0/cc1: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory'

tavianator commented on 2018-01-04 03:47 (UTC)

@sirplatypus: The correct order can be seen here: https://github.com/tavianator/arch-rpi-cross/blob/master/install.sh

sirplatypus commented on 2018-01-04 03:10 (UTC)

Due to the sheer number of errors I have run into trying to compile this package, I am now wondering what the correct way to go about this is. Just trying to compile this package of course does not work, and at this point I have gathered that each dependency must be individually installed in a specific order. What is that order? Thanks

jpartain commented on 2017-10-24 12:13 (UTC) (edited on 2017-10-24 15:00 (UTC) by jpartain)

I tried to install this package yesterday without luck. After adding the needed PGP keys, the arm-linux-gnueabihf-gcc-stage1 package fails to build with: /home/jim/.cache/pacaur/arm-linux-gnueabihf-gcc-stage1/src/gcc/gcc/statistics.h:25:2: error: #error GATHER_STATISTICS must be defined #error GATHER_STATISTICS must be defined ^~~~~ EDIT: It seems the issue was my appending to some environment variables, unsetting them cleared the issue.

Hi-Angel commented on 2017-06-29 08:24 (UTC) (edited on 2017-06-29 08:26 (UTC) by Hi-Angel)

Installed the package two days ago (another computer). For compiling this simple code: #include <string> std::string str; int main() { return 0; } I'm getting: λ arm-linux-gnueabihf-g++ test.cpp -o a /tmp/ccXKFetI.o: In function `__static_initialization_and_destruction_0(int, int)': test.cpp:(.text+0x50): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()' test.cpp:(.text+0x7c): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()' I've tried adding -lstdc++, defining a macro _GLIBCXX_USE_CXX11 to 1 and to 0, but it didn't work. "verbose" shows it's using correct lib paths "/usr/lib/gcc/arm-linux-gnueabihf/…" EDIT: sorry, the text is actually nicely formatted, but site is eating the whitespace.

tavianator commented on 2017-02-03 00:27 (UTC)

@Hi-Angel: You should install the entire base-devel group for building packages. From https://wiki.archlinux.org/index.php/PKGBUILD#makedepends: > Note: The group base-devel is assumed to be already installed when building with makepkg. Members of this group should not be included in makedepends array.

Hi-Angel commented on 2017-01-24 12:59 (UTC)

Please, add bison to dependencies.

xoac commented on 2016-11-16 14:48 (UTC)

@tavianator It is normal that there is no libstdc++.a? My linker yell: /usr/bin/arm-linux-gnueabihf-ld: cannot find -lstdc++ I need to compile my application static. If I compile without `-static` everything works fine!

tavianator commented on 2016-07-29 21:12 (UTC)

@1ace: What patch?

1ace commented on 2016-07-29 09:03 (UTC)

Your patch doesn't apply anymore, looks like it needs to be rebased :)

tavianator commented on 2015-12-11 22:50 (UTC)

@zenolijo: I hear that it's possible to do a 2-stage cross-compiler build, but I'm not sure how. If anyone knows I'm happy to accept patches!

rpodgorny commented on 2015-11-04 22:08 (UTC)

@zenolijo: yup, just follow the dependency chain replacing gcc with the appropriate stages as you go...

zenolijo commented on 2015-11-04 20:49 (UTC)

This package conflicts with gcc-stage1 and 2, glibc has gcc-stage2 as a makedepend and glibc-headers depends on gcc-stage1. So i compile gcc two times, and then finally replace it with a third one? I have no experience with cross compiling, but is this really necessary?

FreddieChopin commented on 2015-10-16 16:15 (UTC)

Hmm... For now I'm using the toolchain provided by ArchLinuxArm. GCC accepts the options, but I'm reluctant to consider that as a confirmation of full compatibility (; I think that to work with multiple targets this toolchain would need a multilib, and this could be pretty complicated. The multilib configuration for bare-metal ARM microcontrollers is pretty complex, this one would probably be comparable (at least).

tavianator commented on 2015-10-16 14:41 (UTC)

@FreddieChopin: The only ARM devices I can test on are RPis, so I'm not really sure! But I assume that if gcc accepts the flags then it should work. The main thing I'd worry about is the calling conventions with glibc, you may have to recompile that.

FreddieChopin commented on 2015-10-15 09:21 (UTC)

Small question - if I want to compile for BeagleBone Black (with Arch installed), can I use this toolchain (configured as "--with-arch=armv6 --with-float=hard --with-fpu=vfp") but passing "-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" to the compiler, or maybe I should recompile the whole toolchain (and its dependencies) with correct flags? The standard "Hello world" test program works with the first option, but is doesn't use FPU (;

tavianator commented on 2015-09-18 00:24 (UTC)

@kozzi: Okay great! I should've put some more minimal version requirements on these packages I guess. Next update I'll do that :)

kozzi commented on 2015-09-17 11:10 (UTC)

@tavianator So after remove all of my arm-linux-gnueabihf* packages, everything seems OK. So it has been probably caused by some obsolete package from 4.9 version

kozzi commented on 2015-09-17 06:59 (UTC)

@tavianator I will remove all my arm-linux-gnueabihf* packages and try it again from scratch

kozzi commented on 2015-09-17 06:56 (UTC)

@tavianator [kozak@dajinka gcc-build]$ cat /var/lib/pacman/local/arm-linux-gnueabihf-glibc-2.22-3/files | grep stubs usr/arm-linux-gnueabihf/include/bits/libm-simd-decl-stubs.h usr/arm-linux-gnueabihf/include/gnu/stubs-soft.h usr/arm-linux-gnueabihf/include/gnu/stubs.h

tavianator commented on 2015-09-16 23:37 (UTC)

@kozzi: $ pacaur -Qo /usr/arm-linux-gnueabihf/include/gnu/stubs-hard.h /usr/arm-linux-gnueabihf/include/gnu/stubs-hard.h is owned by arm-linux-gnueabihf-glibc 2.22-3 Do you not have this file? Do you have the right version of arm-linux-gnueabihf-glibc installed?

kozzi commented on 2015-09-16 15:03 (UTC)

http://pastebin.ca/3162645

tavianator commented on 2015-09-15 22:10 (UTC)

@kozzi: Can you post the exact error message please?

kozzi commented on 2015-09-15 13:29 (UTC)

I am unable to build this package, it says something about missing stubs-hard.h