Arch Linux User Repository

Installing this toolchain is pretty awkward.

• It will import PGP keys that you do not know/trust.
• It depends on arm-linux-gnueabihf-gcc-glibc, which depends on arm-linux-gnueabihf-gcc-stage2, but does not resolve it as a dependency.
• arm-linux-gnueabihf-gcc-stage2 depends on arm-linux-gnueabihf-gcc-glibc, creating a circular dependency.
• arm-linux-gnueabihf-gcc-stage2 depends on -- but conflicts with -- arm-linux-gnueabihf-gcc-stage1. IMO, the stage[12] packages should not be separate AUR packages.
• This process involves cloning the gcc repo three times and the glibc repo twice.
• Due to all of this, building the toolchain will take over 11GB of space.

In case it helps anyone, here's the current functional process until this is fixed and/or streamlined:

1. Create and configure an isolated PGP keyring directory for AUR:

   (umask 077 && mkdir -p ~/.gnupg-aur)
   export GNUPGHOME=$HOME/.gnupg-aur
   

2. Install arm-linux-gnueabihf-gcc-stage1 from AUR (with -binutils dependency).

3. Install arm-linux-gnueabihf-gcc-stage2 from AUR (with -glibc-headers dependency).
   • You can't choose -glibc, because you'll hit a circular dependency.
   • -gcc-stage2 will conflict with the -gcc-stage1 package. You'll need to remove -gcc-stage1 after building -gcc-stage2, but before installing it.
4. Install arm-linux-gnueabihf-gcc from AUR (with -glibc dependency).
   • -glibc will conflict with the -glibc-headers package. You'll need to remove it before installing -glibc.
   • -gcc will conflict with the -gcc-stage2 package. You'll need to remove -gcc-stage2 after building -gcc, but before installing it.

Hmm yeah, didn't notice that because I always use my gcc-snapshot. I will fix it.

I am getting conflicts with gcc 14.2.1 with this package:

(1/1) checking for file conflicts                                           [###########################################] 100%
error: failed to commit transaction (conflicting files)
arm-linux-gnueabihf-gcc: /usr/share/gcc-14.2.1/python/libstdcxx/__init__.py exists in filesystem (owned by gcc)
arm-linux-gnueabihf-gcc: /usr/share/gcc-14.2.1/python/libstdcxx/v6/__init__.py exists in filesystem (owned by gcc)
arm-linux-gnueabihf-gcc: /usr/share/gcc-14.2.1/python/libstdcxx/v6/printers.py exists in filesystem (owned by gcc)
arm-linux-gnueabihf-gcc: /usr/share/gcc-14.2.1/python/libstdcxx/v6/xmethods.py exists in filesystem (owned by gcc)

I've rebuild it from scratch (with stage1/stage2 included) and the issue has gone, thanks wgottwalt!

Did you really built your complete toolchain from scratch? I did so minutes ago:

# l /usr/bin/arm-linux-gnueabihf-*
-rwxr-xr-x 1 root root  1111368 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-addr2line*
-rwxr-xr-x 2 root root  1143920 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-ar*
-rwxr-xr-x 2 root root  2115768 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-as*
-rwxr-xr-x 2 root root  1555056 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-c++*
-rwxr-xr-x 1 root root  1106760 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-c++filt*
-rwxr-xr-x 1 root root  1555136 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-cpp*
-rwxr-xr-x 1 root root  3033408 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-dwp*
-rwxr-xr-x 2 root root  1555056 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-g++*
-rwxr-xr-x 2 root root  1555168 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcc*
-rwxr-xr-x 2 root root  1555168 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcc-14.2.0*
-rwxr-xr-x 1 root root    31672 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcc-ar*
-rwxr-xr-x 1 root root    31672 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcc-nm*
-rwxr-xr-x 1 root root    31672 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcc-ranlib*
-rwxr-xr-x 1 root root   693352 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcov*
-rwxr-xr-x 1 root root   568280 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcov-dump*
-rwxr-xr-x 1 root root   606016 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gcov-tool*
-rwxr-xr-x 1 root root  1565216 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-gm2*
-rwxr-xr-x 4 root root  2210136 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-ld*
-rwxr-xr-x 4 root root  2210136 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-ld.bfd*
-rwxr-xr-x 2 root root  5770648 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-ld.gold*
-rwxr-xr-x 1 root root    11055 Aug  7 06:00 /usr/bin/arm-linux-gnueabihf-ldd*
-rwxr-xr-x 1 root root 39757680 Aug  7 06:09 /usr/bin/arm-linux-gnueabihf-lto-dump*
-rwxr-xr-x 2 root root  1132584 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-nm*
-rwxr-xr-x 2 root root  1270960 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-objcopy*
-rwxr-xr-x 2 root root  1982664 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-objdump*
-rwxr-xr-x 2 root root  1143952 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-ranlib*
-rwxr-xr-x 2 root root  1055336 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-readelf*
-rwxr-xr-x 1 root root  1111112 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-size*
-rwxr-xr-x 1 root root  1119464 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-strings*
-rwxr-xr-x 2 root root  1270960 Aug  7 05:45 /usr/bin/arm-linux-gnueabihf-strip*

# l /usr/lib/gcc/arm-linux-gnueabihf/14.2.0/
drwxr-xr-x 7 root root      4096 Aug  7 06:25 ./
drwxr-xr-x 3 root root      4096 Aug  7 06:25 ../
-rwxr-xr-x 1 root root  41355488 Aug  7 06:09 cc1*
-rwxr-xr-x 1 root root 122934144 Aug  7 06:09 cc1gm2*
-rwxr-xr-x 1 root root  44194384 Aug  7 06:09 cc1plus*
-rwxr-xr-x 1 root root    635496 Aug  7 06:09 collect2*
-rw-r--r-- 1 root root      1776 Aug  7 06:09 crtbegin.o
-rw-r--r-- 1 root root      2124 Aug  7 06:09 crtbeginS.o
-rw-r--r-- 1 root root      2068 Aug  7 06:09 crtbeginT.o
-rw-r--r-- 1 root root       988 Aug  7 06:09 crtend.o
-rw-r--r-- 1 root root       988 Aug  7 06:09 crtendS.o
-rw-r--r-- 1 root root       876 Aug  7 06:09 crtfastmath.o
drwxr-xr-x 3 root root      4096 Aug  7 06:25 include/
drwxr-xr-x 2 root root      4096 Aug  7 06:25 include-fixed/
drwxr-xr-x 3 root root      4096 Aug  7 06:25 install-tools/
-rw-r--r-- 1 root root   1313210 Aug  7 06:09 libgcc.a
-rw-r--r-- 1 root root     20368 Aug  7 06:09 libgcc_eh.a
-rw-r--r-- 1 root root     42570 Aug  7 06:09 libgcov.a
-rwxr-xr-x 1 root root     84016 Aug  7 06:09 liblto_plugin.so*
-rwxr-xr-x 1 root root   1172744 Aug  7 06:09 lto-wrapper*
-rwxr-xr-x 1 root root  39761128 Aug  7 06:09 lto1*
drwxr-xr-x 7 root root      4096 Aug  7 06:25 m2/
drwxr-xr-x 3 root root      4096 Aug  7 06:25 plugin/

Maybe you got some odd local make.conf options or your host compiler is broken. The only big one here is cc1gm2 with ~122 MB. But yeah, there is still some room for stripping.

After 14.2 update, package net upgrade size was 1395 MB. Some files are really huge now:

cc1 - 321 MB, cc1gm2 - 312 MB, cc1plus - 338 MB, lto1 - 303 MB, arm-linux-gnueabihf-lto-dump - 303 MB

Did you rebuild the whole chain starting by binutils? This libiberty issue often comes from a mismatching binutil/gcc build.

Running into this error right now, currently trying to figure out if it could be a misconfiguration on my system:

../../../gcc-13.2.0/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’:
../../../gcc-13.2.0/libiberty/fibheap.c:38:25: error: ‘LONG_MIN’ undeclared (first use in this function)
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  220 |   if (okey == key && okey != FIBHEAPKEY_MIN)
      |                              ^~~~~~~~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c:36:1: note: ‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?
   35 | #include "fibheap.h"
  +++ |+#include <limits.h>
   36 | 
../../../gcc-13.2.0/libiberty/fibheap.c:38:25: note: each undeclared identifier is reported only once for each function it appears in
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  220 |   if (okey == key && okey != FIBHEAPKEY_MIN)
      |                              ^~~~~~~~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c: In function ‘fibheap_delete_node’:
../../../gcc-13.2.0/libiberty/fibheap.c:38:25: error: ‘LONG_MIN’ undeclared (first use in this function)
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  261 |   fibheap_replace_key (heap, node, FIBHEAPKEY_MIN);
      |                                    ^~~~~~~~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c:38:25: note: ‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
../../../gcc-13.2.0/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  261 |   fibheap_replace_key (heap, node, FIBHEAPKEY_MIN);
      |                                    ^~~~~~~~~~~~~~

Flex is not really the issue, you didn't install base-devel. Though, seeing that the Modula-2 guys rely on the old lexer/parser combo (f)lex and yacc/bison is kind of funny. It is old-school, just like Modula-2. ;-)

This currently fails for me with

flex -t ../../gcc-13.2.0/gcc/m2/mc/mc.flex > mcflex.c
mkdir -p -- m2/gm2-libs
/bin/sh: line 1: flex: command not found
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
mkdir -p -- m2/boot-bin

installing the flex package fixed it, the author should update its dependencies to include flex.