How to install arm-none-eabi-gdb on Ubuntu 20.04 LTS (Focal Fossa)
As far as I understand — gcc-arm-embedded doesn’t have a version for Ubuntu 20. So I’ve changed release version for this PPA in Software & Updates to bionic so that I can avoid error 404. Even though ubuntu 20 has libisl22, now I have unmet dependencies when I try to install gcc-arm-embedded:
The following packages have unmet dependencies: gcc-arm-embedded : Depends: libisl15 (>= 0.15) but it is not installable E: Unable to correct problems, you have held broken packages. I was unable to find a way to install requested version of libisl, as apt offers only two versions — libisl22 and libisl-dev and both are not accepted by installer. I need advice on how to install arm-none-eabi-gdb. Thank you!
Not really. I’ve found out, that there is a version for focal on launchpad: launchpad.net/ubuntu/focal/+source/gcc-arm-none-eabi But I have no idea why ppa doesn’t give access to it.
@AleksanderKhoroshko Although they have package for focal but they do miss the folder in dists and release file. Release file contains the path of the deb in the pool which is to be fetched when requested. Neither they uploaded the package in pool of archives. You may consider contacting the PPA maintainer regarding the same.
@Kulfy thank you for your effort! It turned out that PPA maintainer decided to deprecate this PPA (it is in the notes on their website), so now non-PPA way of installation is the only way to go. I’ve made an answer below with instructions.
4 Answers 4
It turned out that ARM decided to make our life easier (sarcasm) by deprecating the use of PPA — their page at launchpad now has an anouncement: «. all new binary and source packages will not be released on Launchpad henceforth . «.
So, to make use of their latest arm-none-eabi-gdb you have to install gcc-arm-embedded manually.
Remove arm-none-eabi-gcc from your system:
sudo apt remove gcc-arm-none-eabi Download latest version (Linux x86_64 Tarball) from their website, check its MD5. Unpack it into some directory. I used /usr/share/ :
sudo tar xjf gcc-arm-none-eabi-YOUR-VERSION.bz2 -C /usr/share/
Create links so that binaries are accessible system-wide:
sudo ln -s /usr/share/gcc-arm-none-eabi-YOUR-VERSION/bin/arm-none-eabi-gcc /usr/bin/arm-none-eabi-gcc sudo ln -s /usr/share/gcc-arm-none-eabi-YOUR-VERSION/bin/arm-none-eabi-g++ /usr/bin/arm-none-eabi-g++ sudo ln -s /usr/share/gcc-arm-none-eabi-YOUR-VERSION/bin/arm-none-eabi-gdb /usr/bin/arm-none-eabi-gdb sudo ln -s /usr/share/gcc-arm-none-eabi-YOUR-VERSION/bin/arm-none-eabi-size /usr/bin/arm-none-eabi-size sudo ln -s /usr/share/gcc-arm-none-eabi-YOUR-VERSION/bin/arm-none-eabi-objcopy /usr/bin/arm-none-eabi-objcopy Install dependencies. ARM’s «full installation instructions» listed in readme.txt won’t tell you what dependencies are — you have to figure it out by trial and error. In my system I had to manually create symbolic links to force it to work:
sudo apt install libncurses-dev sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5 sudo ln -s /usr/lib/x86_64-linux-gnu/libtinfo.so.6 /usr/lib/x86_64-linux-gnu/libtinfo.so.5 arm-none-eabi-gcc --version arm-none-eabi-g++ --version arm-none-eabi-gdb --version arm-none-eabi-size --version @AleksanderKhoroshko OMG, we’ve been unwittingly using old tools for ages. Thank you thank you! Bit evil of ARM to leave the old stuff up there. hmm. Ok, I’ve just raised a flag to say your question should be reopened, because the listed alternative qqs are nothing to do with this specific problem.
I tried this package»gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2″, needn’t manually create symbolic links, the result for «Check if it works: » was OK.
I suggest symlinking everything in the bin folder — sudo ln -s /usr/share/gcc-arm-none-eabi-your-version/bin/* /usr/bin/
I’ve wrapped the script here by @kmhallen into a semi-automated debian package builder here: https://gitlab.com/alelec/arm-none-eabi-gcc-deb/-/releases
Installing a package like this means you can skip the tedious manual symlinks to put tools on the path, and just as importantly you can uninstall / upgrade to newer packages (assuming I remember to make more packages)
The answer from Aleksander solved 99 percent of my issues, however after running make I got one error arm-none-eabi-objcopy : command not found. So I had do make one more symlink to get the files generated.
sudo ln -s /usr/share/gcc-arm-none-eabi-your-version/bin/arm-none-eabi-objcopy /usr/bin/arm-none-eabi-objcopy
I tried to add this as comment to the answer but I don’t have enough points to do that.
Welcome to Ask Ubuntu! I’ve gone ahead and added your suggestion to the answer you referred to. Please do not leave comments in answers. Instead, you can post answers that do not require clarification from the question author, or, if you have a suggestion, edit the post to incorporate your suggestion.
After extracting, add the path to the bin folder to the system path:
cd /opt wget "https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2" tar -jxf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 rm gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 export PATH="/opt/gcc-arm-none-eabi-10.3-2021.10/bin:$PATH" Alternatively, here is a script to generate a Debian package and install it to the /usr directory. This way you don’t have to export the path all the time, and it can be removed with sudo apt purge gcc-arm-none-eabi
#!/bin/bash VER=15:10.3-2021.10-9 URL=https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 echo "Creating gcc-arm-none-eabi debian package version $VER" echo "Entering temporary directory. " cd /tmp echo "Downloading. " curl -fSL -A "Mozilla/4.0" -o gcc-arm-none-eabi.tar "$URL" echo "Extracting. " tar -xf gcc-arm-none-eabi.tar rm gcc-arm-none-eabi.tar echo "Generating debian package. " mkdir gcc-arm-none-eabi mkdir gcc-arm-none-eabi/DEBIAN mkdir gcc-arm-none-eabi/usr echo "Package: gcc-arm-none-eabi" > gcc-arm-none-eabi/DEBIAN/control echo "Version: $VER" >> gcc-arm-none-eabi/DEBIAN/control echo "Architecture: amd64" >> gcc-arm-none-eabi/DEBIAN/control echo "Maintainer: maintainer" >> gcc-arm-none-eabi/DEBIAN/control echo "Description: Arm Embedded toolchain" >> gcc-arm-none-eabi/DEBIAN/control mv gcc-arm-none-eabi-*/* gcc-arm-none-eabi/usr/ dpkg-deb --build --root-owner-group gcc-arm-none-eabi echo "Installing. " sudo apt install ./gcc-arm-none-eabi.deb -y --allow-downgrades echo "Removing temporary files. " rm -r gcc-arm-none-eabi* echo "Done." Difference between arm-eabi arm-gnueabi and gnueabi-hf compilers [closed]
Closed. This question is seeking recommendations for books, tools, software libraries, and more. It does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
What is the difference between arm-eabi, gnueabi and gnueabi-hf cross compilers? I am kind of finding it difficult to choose the executable that is correct for my target platform. Is there a native compiler for arm?
1 Answer 1
- the eabi stands for the compilation of code which will run on bare metal arm core.
- the gnueabi stands for the compilation of code for linux
For the gnueabi/gnueabi-hf part, I found an answer here.
gcc-arm-linux-gnueabi is the cross-toolchain package for the armel architecture. This toolchain implies the EABI generated by gcc’s -mfloat-abi=soft or -mfloat-abi=softfp options.
gcc-arm-linux-gnueabihf is the cross-toolchain package for the armhf architecture. This toolchain implies the EABI generated by the gcc -mfloat-abi=hard option.
‘hf’ means hard-float which indicates that the compiler and its underlying libraries are using hardware floating point instructions rather than a software implementation of floating point such as fixed point software implementations. The ‘eabi’ refers to what the underlying binary is going to look like. It can be argued that these can be achieved with flags to gcc but the issue is that of bare metal pre-compiled libraries. Unless you are recompiling everything from source, it may not be feasible to use gcc with flags alone. Even in that case you might have to carefully configure each package or library with the appropriate compile options.
Difference between arm-none-eabi and arm-linux-gnueabi?
What is the difference between arm-none-eabi and arm-linux-gnueabi? I know the difference in how to use them (one for bare metal software, the other one for software meant to be run on linux). But what is the technical background? I see there is a difference in the ABI which is, as far as I understood, something like an API but on binary level. It ensures interoperability of different applications. But I don’t really understand in which way having or not having an operating system affects my toolchain. The only thing that came to my mind is, that libraries maybe have to be statically linked (do they?) while compiling bare metal software, because there is no os dynamically providing them. The most pages I found related to this toppic just answered how to use the toolchains but not the technical background. I’m a student of mechatronics and new to embedded systems, so my experience in this field is somewhat limited.
Yes it is mostly a library thing, trying to tune for running on linux (libc, etc) vs I think newlib. For bare metal work, either is fine as they can both make assembly from C and make objects from assembly and link with your own linker scripts, etc. And the bare metal i am talking about is one without standard libraries and/or you use this tool to create your own libraries from sources. Basically they both work as generic cross compilers, if you want/need built in library support, then it may matter which one you use.
@dwelch: There is no need to use any library on bare-metal. You just possibly have to provide some functions (mostly memcpy , etc.) gcc might call (e.g. when assignming structs ).
@Olaf I dont use C libraries on bare metal, but some folks do, and of those some use newlib (or whatever is friendly to that build), and of those some want to use arm-none-eabi instead of arm-linux-gnueabi because it does matter to them. So it depends on what the OP is targeting as to whether or not the differences matter.
@dwelch: I strongly doubt arm-linux-gnueabi will work for bare-metal systems. Never tried it, though. For one, iirc, arm-none-* is a freestanding implementation by default, so it does not rely on the C stdlib for hosted systems and gcc does not use its built-in optimisations for certain standard library functions.
@Olaf most if not all of my work and personal bare metal code can use either variant as I dont rely on anything but a compiler that can make asm from C and assembler that can make machine code from asm, and a linker that links only the things I have supplied together. It is very dependent though on the user and their code and build system. More likely to get tripped up with the -linux- one. And yes the gcc lib things can very quickly get system dependent so I control those as well.