0

I'm trying to build an older version of GCC toolchain for ARM under x86 because there is a bug with GCC > v5 for Cortex-M0. I'm following the combination of the following instructions:

So my overall procedure is as follows: 

# Download GCC-5.5.0 from https://gcc.gnu.org/releases.html
VERSION="5.5.0"
tar xzf gcc-$VERSION.tar.gz
cd gcc-$VERSION
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
../gcc-5.5.0/configure --prefix=$HOME/embedded/gcc-arm-none-eabi-5.5.0 --disable-multilib --enable-languages=c,c++ --target=arm-none-eabi
make -j$(nproc) # use all cores
make install

Then the following files are created under ~/embedded/arm-none-eabi-5.5.0/bin/: 

arm-none-eabi-c++  arm-none-eabi-gcc-5.5.0   arm-none-eabi-gcov
arm-none-eabi-cpp  arm-none-eabi-gcc-ar      arm-none-eabi-gcov-dump
arm-none-eabi-g++  arm-none-eabi-gcc-nm      arm-none-eabi-gcov-tool
arm-none-eabi-gcc  arm-none-eabi-gcc-ranlib

However, the following command fails: 

arm-none-eabi-gcc -c -mcpu=cortex-m0 -O0 -ggdb (......)

Compiling crt0_v6m.S
as: unrecognized option '-mcpu=cortex-m0'
make: *** [/home/ceremcem/ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:253: build/obj/crt0_v6m.o] Error 1

I can verify that the command uses newly produced binaries: 

$ which arm-none-eabi-gcc
/home/ceremcem/embedded/arm-none-eabi-5.5.0/bin//arm-none-eabi-gcc

This means that the newly compiled GCC toolchain does not accept the mcpu option. What could be wrong with building the GCC toolchain phase that causes -mcpu=cortex-m0 option to fail?

Improve this question
6
  • Have you installed the appropriate cross-binutils? It’s as that’s complaining, and that’s part of binutils. Commented Apr 7, 2019 at 16:47
  • Yes and no. I'm already installed and using arm-none-eabi-gcc v7.3.1 so I assumed the rest of the dependencies are already satisfied by the v7.3.1 installation and ./contrib/download_prerequisites command. Should I build something else? Commented Apr 7, 2019 at 16:52
  • What version of Debian are you using? Commented Apr 7, 2019 at 20:33
  • I'm using Debian Buster/sid (testing). I would like to achieve a distro agnostic solution though. Commented Apr 7, 2019 at 20:37
  • Right, I understand that, I was wondering since Debian 9 has gcc-arm-none-eabi version 5.4.1. Commented Apr 7, 2019 at 20:39

1 Answer 1

Reset to default
2

Your GCC doesn’t appear to be using the right as, and probably wouldn’t use the right ld either; you need to add

--with-as=/usr/bin/arm-none-eabi-as --with-ld=/usr/bin/arm-none-eabi-ld

to your ./configure line.

You’re also likely to run into issues related to Debian’s multi-arch approach, which GCC 5 doesn’t support directly. Your best bet is to download the last Debian package of GCC 5.5 in source form, and use that (with patches) to build your cross-compiler. Then it will use the ARM C library which was installed as a dependency of the cross-GCC package you installed.

dget https://snapshot.debian.org/archive/debian-debug/20180412T094604Z/pool/main/g/gcc-5/gcc-5_5.5.0-12.dsc
cd gcc-5-5.5.0
debian/rules patch

then configure and build as before. (Ignore the cross-building documentation in debian/README.cross.)

Improve this answer
3
  • This didn't solve all issues but made the problem proceed to another step: Now it can't find stdint.h while compiling an application, very much like the problem I've faced 4 years ago: stackoverflow.com/q/23973971/1952991 Commented Apr 7, 2019 at 17:49
  • That’s because it’s looking for headers in the upstream location, not in the multiarch location; see my updated answer for a fix. Commented Apr 7, 2019 at 19:14
  • No luck, very same issue persists. Note that the /usr/lib/gcc/arm-none-eabi/7.3.1/include/ folder contains many *.h files but the include folder in newly compiled gcc installation location is still empty. Commented Apr 7, 2019 at 20:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.