C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

Freddie Chopin freddie_chopin@op.pl
Fri Aug 18 18:23:00 GMT 2017


On Fri, 2017-08-18 at 11:17 -0500, R0b0t1 wrote:
> Just to check, this is actually an
> arm-none-eabi toolchain? I looked over the compilation flags and it
> looks like it supports all Cortex-M processor features like such a
> toolchain should. Most instructions I could find seemed to build a
> more restricted toolchain.

The toolchain you get from this script supports - in case of GCC 7 -
following multilibs:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
hard;@mfloat-abi=hard
thumb/v6-m;@mthumb@march=armv6s-m
thumb/v7-m;@mthumb@march=armv7-m
thumb/v7e-m;@mthumb@march=armv7e-m
thumb/v7-ar;@mthumb@march=armv7
thumb/v8-m.base;@mthumb@march=armv8-m.base
thumb/v8-m.main;@mthumb@march=armv8-m.main
thumb/v7e-m/fpv4-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5/hard;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=hard
thumb/v7-ar/fpv3/softfp;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp
thumb/v7-ar/fpv3/hard;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5-sp/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5-sp/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=hard

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

That means you can use all ARM Cortex-M chips, with or without FPU, 32-
bit or 64-bit. You can also use ARM Cortex-R and "classic" ARM7TDMI.

This is the same set of architectures you get from the toolchain
provided by ARM.

> I have looked at the supporting blog posts and read the documentation
> available.

The blog post is really old and the part about performance is mostly
obsolte (;

> I still do not understand why the specific binutils, gcc,
> newlib, and gdb configurations were chosen, and why what is
> ostensibly
> the same configuration failed when I tried it Would you please take
> the time to document them, or point me towards a place that describes
> what I should be looking for and why? I don't mind reading but I do
> not know why the choices made are the correct ones and have been
> unable to find anywhere that starts to offer any explanation.

Generally I used the most recent components which are available for
download.

In the past - up to and including GCC 6 - the only exception were the
cases of supporting libraries (stuff like isl, mpfr, ...), where
_sometimes_ gcc docs say you must use a release from range x-y, not the
most recent one. In that case the most recent package from the range is
chosen. However the file gcc-7.2.0/gcc/doc/install.texi always says
"version x (or later)" so... I use the most recent one (; After all,
this is a "bleeding-edge" toolchain (;

Sometimes the version may be a bit older than the most recent one
either because I forgot to check, or because the most recent one has
some problems. This is the case for the most recent newlib snapshot
which fails to build for ARM - that's why I had to use a previous one.

Regards,
FCh



More information about the Gcc mailing list