18.04 breaks firmware builds

Bug #1772332 reported by Paul Selkirk
This bug report is a duplicate of:  Bug #1767223: multilib selects wrong start files. Edit Remove
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
Invalid
Undecided
Unassigned
newlib (Debian)
Fix Released
Unknown
newlib (Ubuntu)
Fix Released
Undecided
Unassigned

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

Revision history for this message
Tejas Belagod (belagod-tejas) wrote :

Hi,

We don't guarantee the toolchain works with newlibs that aren't supplied with the GNU ARM Embedded toolchain.

Thanks,
Tejas.

Revision history for this message
Paul Selkirk (paul-natyyjkkrqk00yyc0osbu) wrote :

When you say "we", do you mean ARM or Canonical?

If this is not the correct forum to report an integration problem that affects the toolchain, could you please tell me what is.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) wrote :

These are packages provided by Ubuntu which take them from Debian, you should be using gcc-arm-embedded from the PPA (follow the link from the overview page to the PPA and follow the instructions to add it) to use our toolchain.

FYI: I've raised bug #899264 [1] in Debian to solve the problem you have.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899264

Best regards,

Thomas

Changed in gcc-arm-embedded:
status: New → Invalid
Changed in newlib (Debian):
status: Unknown → New
Changed in newlib (Debian):
status: New → Fix Released
Revision history for this message
Björn Haase (sp0001) wrote :

I stumbled over the very same issue. It seems actually be a topic for ubuntu rather than debian.

I've filed a bug report also for ubuntu:

https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1804922

Changed in newlib (Ubuntu):
status: New → Fix Released
Revision history for this message
Amr Ibrahim (amribrahim1987) wrote :

If this bug is not a duplicate of bug #1767223, please remove the linked duplicate bug.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.