Package Details: arm-linux-gnueabi-gcc 16.1.0-1

Git Clone URL: https://aur.archlinux.org/arm-linux-gnueabi-gcc.git (read-only, click to copy)
Package Base: arm-linux-gnueabi-gcc
Description: The GNU Compiler Collection - cross compiler for ARM GNU EABI little-endian target
Upstream URL: http://gcc.gnu.org/
Licenses: GFDL-1.3-or-later, GPL-3.0-or-later WITH GCC-exception-3.1
Submitter: Megver83
Maintainer: bschnei (pdlloyd)
Last Packager: bschnei
Votes: 8
Popularity: 0.025928
First Submitted: 2018-05-05 22:58 (UTC)
Last Updated: 2026-05-22 05:28 (UTC)

Latest Comments

1 2 Next › Last »

bschnei commented on 2026-05-22 18:59 (UTC)

@gyscos, no problem :) I had been cleaning up the package for awhile and testing that I could add aarch64 support which is why the update to 16.1 is actually delayed (16.1 has been out for a while). I wasn't aware, though, that 15.2 would no longer build so thank you for raising!

gyscos commented on 2026-05-22 16:57 (UTC) (edited on 2026-05-23 18:17 (UTC) by gyscos)

Thanks a lot for the quick update! I confirm it now builds fine.

bschnei commented on 2026-05-22 05:46 (UTC)

@gyscos try 16.1.0-1 :)

gyscos commented on 2026-05-21 22:46 (UTC)

It looks like this package is not building properly. Could it be because the "standard" gcc package was updated to 16?

LLM analysis:

Root cause: GCC 15.2.0's libcody uses u8" " UTF-8 string literals and passes them to S2C(), which expects const char (&)[I]. In C++17, u8"" literals had type const char[] — fine. In C++20, they became const char8_t[] — a distinct type that doesn't match. The build host is GCC 16.1.1, which defaults to C++20, so const char8_t [2] vs. const char causes a hard type mismatch across dozens of call sites.

Short version: GCC 15.2.0's libcody has a bug where it's incompatible with being built by GCC 16's default C++ standard. This is a known upstream issue with that AUR package — the PKGBUILD would need to pass -std=c++17 (or a patch) when compiling libcody.

bschnei commented on 2025-05-01 16:15 (UTC)

Hi @curlywei, most users of this package are not going to get notifications of posts here so it is not an ideal place for support unless you think something is wrong with the package itself. I suspect you are encountering that error because this package does not install headers to the host system. The project I use this cross compiler for includes the headers it needs as part of the project itself so I do not encounter this error. You should be able to get standard headers and install/manage them manually and then use one of the configuration options noted here to tell the compiler where to find them: https://stackoverflow.com/questions/36271124/referring-to-architecture-specific-headers-in-cross-compile

curlywei commented on 2025-05-01 09:30 (UTC)

Does anyone encounter this problem while using g++? 

> $ arm-linux-gnueabi-g++ -static t.cc -o t.elf
t.cc:1:10: fatal error: iostream: No such file or directory
    1 | #include <iostream>
      |          ^~~~~~~~~~
compilation terminated.

1 2 Next › Last »