[Bug 1772332] Re: 18.04 breaks firmware builds

[Thomas Preud'homme]

** Also affects: newlib (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to newlib in Ubuntu.
https://bugs.launchpad.net/bugs/1772332

Title:
  18.04 breaks firmware builds

Status in GNU Arm Embedded Toolchain:
  Invalid
Status in newlib package in Ubuntu:
  New
Status in newlib package in Debian:
  Fix Released

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

  Symptoms:

  Trying to link, 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: My 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, which is never okay.

  Root cause analysis:

  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 my 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.

  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1772332/+subscriptions