18.04 breaks firmware builds
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-
Symptoms:
Trying to link, I get one error of the form:
/usr/
and 82 errors of the form:
/usr/
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-
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/
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/
Workarounds:
1. Manually downgrade gcc-arm-none-eabi to 5.4.1.
2. Or manually symlink the affected files:
cd /usr/lib/
sudo ln -s ../../.
sudo ln -s ../../.
Changed in gcc-arm-embedded: | |
status: | New → Invalid |
Changed in newlib (Debian): | |
status: | Unknown → New |
Changed in newlib (Debian): | |
status: | New → Fix Released |
Changed in newlib (Ubuntu): | |
status: | New → Fix Released |
Hi,
We don't guarantee the toolchain works with newlibs that aren't supplied with the GNU ARM Embedded toolchain.
Thanks,
Tejas.