md380tools icon indicating copy to clipboard operation
md380tools copied to clipboard

Ubuntu 18.04 LTS Compatibility (was Make flash not possible, compiler error)

Open HB9SWR opened this issue 6 years ago • 19 comments

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?

HB9SWR avatar May 30 '18 07:05 HB9SWR

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.

DL2MF avatar Jun 02 '18 22:06 DL2MF

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.

travisgoodspeed avatar Jun 03 '18 15:06 travisgoodspeed

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

DL2MF avatar Jun 05 '18 19:06 DL2MF

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

DL2MF avatar Jun 06 '18 14:06 DL2MF

workaround works... :-) Thanks and vy 73

HB9SWR avatar Jun 06 '18 15:06 HB9SWR

Labelled this as a Linux distro bug. We'll leave the ticket up until Ubuntu and Debian fix their stuff, then close the ticket.

travisgoodspeed avatar Jun 06 '18 15:06 travisgoodspeed

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

KD0DOS avatar Sep 16 '18 15:09 KD0DOS

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?

travisgoodspeed avatar Sep 16 '18 15:09 travisgoodspeed

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:

Error.txt

73, Tom

KD0DOS avatar Sep 16 '18 16:09 KD0DOS

@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 avatar Sep 16 '18 16:09 travisgoodspeed

@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 ~$

KD0DOS avatar Sep 16 '18 16:09 KD0DOS

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

stefansaraev avatar Sep 16 '18 16:09 stefansaraev

@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

travisgoodspeed avatar Sep 16 '18 17:09 travisgoodspeed

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

KD0DOS avatar Sep 16 '18 17:09 KD0DOS

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/

andrewc1 avatar Nov 22 '18 07:11 andrewc1

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

Loria avatar Dec 20 '18 10:12 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

tcsmedes avatar Jun 08 '19 02:06 tcsmedes

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

wedgef5 avatar Jul 06 '21 19:07 wedgef5

FYI...this issue is fixed in Ubuntu 20.04.

wedgef5 avatar Jul 12 '21 14:07 wedgef5