search

travisgoodspeed / md380tools

Python tools and patched firmware for the TYT-MD380
804 stars 245 forks source link

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

Open HB9SWR opened 6 years ago

HB9SWR commented 6 years ago

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?

DL2MF commented 6 years ago

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.

travisgoodspeed commented 6 years ago

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.

DL2MF commented 6 years ago

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 commented 6 years ago

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

HB9SWR commented 6 years ago

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

travisgoodspeed commented 6 years ago

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

KD0DOS commented 5 years ago

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

travisgoodspeed commented 5 years ago

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?

KD0DOS commented 5 years ago

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

travisgoodspeed commented 5 years ago

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

KD0DOS commented 5 years ago

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

stefansaraev commented 5 years ago

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
travisgoodspeed commented 5 years ago

@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

KD0DOS commented 5 years ago

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

andrewc1 commented 5 years ago

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/

Loria commented 5 years ago

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

tcsmedes commented 5 years ago

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

wedgef5 commented 3 years ago

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 commented 3 years ago

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