md380tools
md380tools copied to clipboard
Ubuntu 18.04 LTS Compatibility (was Make flash not possible, compiler error)
Hello Unfortunately, I can't compile the FW anymore. This worked without any problems until recently. The md380tools directory has been new cloned by GitHub. Compiler message see attached file. compile_error.txt
My system: Linux version 4.15.0-22-generic (buildd@lgw01-amd64-013) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) 24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018
What am I doing wrong?
Confirmed, same issue on a new dev workstation with Ubuntu 18.04 LTS, but working fine on my current machine with 16.04 LTS. Will check and findout, which package (assume GCC) causes the problem.
Looks like we are accidentally linking against a soft-float version of newlib, while the firmware is compiled to use hardware floating point. I'm not quite sure why we aren't triggering the same problem on Debian/Stable, which uses similar package versions.
This is an Ubuntu bug, reported here: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1772332
Status of the newlib just changed 2h ago, will wait with downgrade:
Changed in newlib (Debian):
status: | New → Fix Released
Current workaround: 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
After linking that two files, make flash_D13 / make flash_S13 is running fine and generating new binaries. Note: Make CI will fail due two different compiler error handling (warnings treated as errors).
workaround works... :-) Thanks and vy 73
Labelled this as a Linux distro bug. We'll leave the ticket up until Ubuntu and Debian fix their stuff, then close the ticket.
Hello, I have a fresh install of Linux Mint 19, Cinnamon Edition, and also have this problem. I have attempted to use the current workaround but the directory does not exist:
~$ cd /usr/lib/arm-none-eabi/newlib/thumb/v7e-m/fpv4-sp/hard bash: cd: /usr/lib/arm-none-eabi/newlib/thumb/v7e-m/fpv4-sp/hard: No such file or directory
Is there anything that I can do to fix this problem besides waiting for Ubuntu/Linux Mint to back-port the Debian fix?
73, Tom
Confirmed that this was fixed in Debian months ago. We can close the issue as soon as someone confirms that it is fixed in Ubuntu. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899264
Tom, why do you think Mint has the same problem as this old Ubuntu bug? What exactly is the first error you see when building md380tools?
Hello Travis, I believe that I have the same problem because I get the same errors that @HB9SWR noted when he opened this issue. Here is the output that I get:
73, Tom
@KD0DOS Try running find /usr/lib/ -name crt0.o | grep arm-none-eabi
to find the proper location of crt0.o
. I think that either the relative paths are different from Debian, or you don't have newlib installed.
@travisgoodspeed Here is the output from that command:
~$ find /usr/lib/ -name crt0.o | grep arm-none-eabi /usr/lib/arm-none-eabi/newlib/armv7e-m/crt0.o /usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/crt0.o /usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-d16/crt0.o /usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-sp-d16/crt0.o /usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/crt0.o /usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/crt0.o /usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-sp-d16/crt0.o /usr/lib/arm-none-eabi/newlib/crt0.o /usr/lib/arm-none-eabi/newlib/armv7-m/crt0.o /usr/lib/arm-none-eabi/newlib/thumb/crt0.o /usr/lib/arm-none-eabi/newlib/fpu/crt0.o /usr/lib/arm-none-eabi/newlib/armv6-m/crt0.o ~$
fyi I've just re-tested, not yet fixed in buntu
binutils-arm-none-eabi=2.27-9ubuntu1+9
gcc-arm-none-eabi=15:6.3.1+svn253039-1build1
libnewlib-arm-none-eabi=2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib=15:6.3.1+svn253039-1+10
@KD0DOS Yup, this is the same bug. The workaround will probably work for you if you adjust the paths.
@stefansaraev Confirmed the bug on a fresh Ubuntu 18 VM. We'll leave this issue standing until the matching Ubuntu bug is fixed, but it looks for now as if the gcc-arm-embedded ppa is the best option for Ubuntu users. https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223
THANK YOU, for all of the information and your time on my comment. Unfortunately I do not have the knowledge of how to adjust the paths for the workaround. If those could be posted I will give them a try.
73, Tom
You can also download a working compiler and build with that - see https://unix.stackexchange.com/questions/453032/how-to-install-a-functional-arm-cross-gcc-toolchain-on-ubuntu-18-04/
Hi,
Ubuntu LTS 18.04.1 still contains this bug.
DL2MF's workaround:
Current workaround: 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
After linking that two files, make flash_D13 / make flash_S13 is running fine and generating new binaries. Note: Make CI will fail due two different compiler error handling (warnings treated as errors).
still works.
73 de Loria
I am trying to install this on Linux Mint 19.1 I get the same errors as above when trying to flash, and I get the same output as KD0DOS when I run the find /usr/lib/ -name crt0.o | grep arm-none-eabi, I do have some experience setting up links and cross links to get compilers to work but have not been able to figure this one out, any help on what needs to be linked where would be hugely appreciated.
Thanks and 73 -Tad K8TCS N-Scale
I have this issue also in Fedora 34. Why there is still a 3+ year old problem in a new Fedora release is beyond me, but here we are. I found F34's newlib object files in /usr/arm-none-eabi, but I'm confused as to what to link to where, as the filenames don't match what was given above. Fedora has the following files when I run a 'find'...
[root@localhost usr]# find . -name crt0.o ./arm-none-eabi/lib/arm/v5te/hard/crt0.o ./arm-none-eabi/lib/arm/v5te/softfp/crt0.o ./arm-none-eabi/lib/thumb/v7-m/nofp/crt0.o ./arm-none-eabi/lib/thumb/v7+fp/hard/crt0.o ./arm-none-eabi/lib/thumb/v7+fp/softfp/crt0.o ./arm-none-eabi/lib/thumb/v8-m.main/nofp/crt0.o ./arm-none-eabi/lib/thumb/v7/nofp/crt0.o ./arm-none-eabi/lib/thumb/v8-m.base/nofp/crt0.o ./arm-none-eabi/lib/thumb/v6-m/nofp/crt0.o ./arm-none-eabi/lib/thumb/v7e-m/nofp/crt0.o ./arm-none-eabi/lib/thumb/v8.1-m.main+mve/hard/crt0.o ./arm-none-eabi/lib/thumb/v7-r+fp.sp/hard/crt0.o ./arm-none-eabi/lib/thumb/v7-r+fp.sp/softfp/crt0.o ./arm-none-eabi/lib/thumb/v7e-m+dp/hard/crt0.o ./arm-none-eabi/lib/thumb/v7e-m+dp/softfp/crt0.o ./arm-none-eabi/lib/thumb/v8-m.main+fp/hard/crt0.o ./arm-none-eabi/lib/thumb/v8-m.main+fp/softfp/crt0.o ./arm-none-eabi/lib/thumb/nofp/crt0.o ./arm-none-eabi/lib/thumb/v7e-m+fp/hard/crt0.o ./arm-none-eabi/lib/thumb/v7e-m+fp/softfp/crt0.o ./arm-none-eabi/lib/thumb/v8-m.main+dp/hard/crt0.o ./arm-none-eabi/lib/thumb/v8-m.main+dp/softfp/crt0.o ./arm-none-eabi/lib/crt0.o
Can someone clue me in as to what I should link? I do quite a bit of Linux work, but this is over my head!
73, Matt N0EYE
FYI...this issue is fixed in Ubuntu 20.04.