[Cryptech Tech] Ubuntu 18.04 breaks firmware builds

[Paul Selkirk]

Specifically, the combination of gcc-arm-none-eabi 6.3.1 and
libnewlib-arm-none-eabi 2.4.0 breaks firmware builds.

Trying to link hsm.elf, I get one error of the form:

  /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o:
Conflicting CPU architectures 13/1

and 82 errors of the form:

  /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error:
hsm.elf uses VFP register arguments,
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libg.a(lib_a-assert.o)
does not

(one for every object linked from libg.a).

Translation: Our code is built to use the hardware Floating-Point Unit,
but libg.a is built to use software floating-point, which you might
think would be okay, but isn't. Also, crt0.o is built for a different
CPU architecture. Not good.

What happened:

gcc-arm-none-eabi and libnewlib-arm-none-eabi each have a pile of
arch-specific directories for libraries and crt*.o files. gcc intuits
the proper directory (combination of ARM version and floating-point
support) from arch-specific cflags (in our case: -mcpu=cortex-m4 -mthumb
-mlittle-endian -mthumb-interwork -mfloat-abi=hard -mfpu=fpv4-sp-d16).

For reasons that are still unclear, gcc-arm-none-eabi 6.3.1 changed its
lib directory structure, e.g. 5.4.1/armv7e-m/fpu ->
6.3.1/thumb/v7e-m/fpv4-sp/hard. And it seems to expect that newlib will
use the same directory structure. But newlib wasn't revved in this
release (it went from version 2.4.0.20160527-2 to 2.4.0.20160527-3), so
it has the old directory structure.

Finally, for reasons that are super unclear, if ld doesn't find the
library or object file it's looking for, it doesn't complain, but
defaults to the same file in its top-level directory. e.g. If it can't
find /usr/lib/arm-none-eabi/lib/armv7e-m/fpu/crt0.o, it uses
/usr/lib/arm-none-eabi/lib/crt0.o.

For once, google and stackoverflow were no help, except to point me at
the -Wl,--trace link option, which is how I figured out which directory
it really wanted.

Workarounds:

1. Manually downgrade gcc-arm-none-eabi to 5.4.1.

2. Or manually symlink the affected files:

   cd /usr/lib/arm-none-eabi/newlib/thumb/v7e-m/fpv4-sp/hard
   sudo ln -s ../../../../armv7e-m/fpu/crt0.o crt0.o
   sudo ln -s ../../../../armv7e-m/fpu/libg.a libg.a

				paul