Name: GNU Compiler Collection ARM Embedded.
Home Page: https://launchpad.net/gcc-arm-embedded
Name: GNU Compiler Collection ARM Embedded.
I'm in a robotics team (FRC) and do all my programing in c++. We have to program a device called the RoboRIO witch is an arm based Linux device. All my code gets cross compiled over to arm from my laptop using eclipse as the IDE and GCC set up for arm under the Hood.They provide their own tool-chain but all it is a GCC set up to cross compile to arm with frc- in front of the executable. It pretty Much the same concept as the Arduino with AVR support, it gets compiled on the computer and then pushed to the device by a serial connection.
The source downloads for the gcc-arm-none-eabi are have moved to developer.arm.com as per the note on the launchpad page.
I'll just note that this is pretty vital in developing for ARM microcontrollers. Normal workflow with the OpenSTM32 toolchain in my case, has the plugins installer try to handle everything but fail because it explicitly requires the 32-bit C shared libraries and compiler.
So I gave it a try today, but I'm not sure how to proceed. The aforementioned toolchain contains everything (GNU C/C++ Compiler, Binutils, GDB and Newlib) and looks like it's thought to build it on your own since the scripts pull all needed packages without any checksum verification.
The other way would be to provide the single packages - when you take a look at the "arch enemy", they provide:
all built from their respective source. I think the latter would be preferred, but since I wouldn't be using it I wait for someone's answer :)
This has sat in accepted for inclusion for over a year. Clearly, there is a lack of demand for the inclusion of this software, nobody has stepped up to provide a patch, maintain it, and properly integrate it. Closing as a result. Feel free to reopen but only when someone offers a patch via our proper patch submission methods and volunteers to be maintainer.
Guys, i managed to build all four packages using Solus packaging system, all from their respective sources.
I might volunteer to be maintainer for those, and also for AVR toolchain (similar to ARM but different arch target).
I just had one problem while building these packages, because we have circular dependency.
I will try to explain it here.
So, to build binutils, you just build it normally, no extra dependencies needed.
To build gcc, you need binutils (which you just built) and newlib (which you still don't have).
To build newlib, you need gcc and now you have circular dependency.
To solve this, you can build barebone gcc compiler without newlib support, deploy it on "local" repo, set it as dependency to newlib, and then build newlib with this barebone gcc.
Now you have newlib, but it has wrong package definition (wrong dependency), but you can still use it in your local repo to finally build full gcc with newlib support.
Now you have to rebuild newlib again, set correct gcc as dependency and that's it.
The problem with this approach is, you only accept package definitions in form of yml files, and no binary eopkg files, so automatic build server is not able to build it that way.
One way to solve this problem is to publish this barebone gcc package as separate package that we can depracate as soon as we build this newlib, and set full gcc package to 'replace' this barebone version.
Another solution is to build full toolchain from single tarball which is published on official arm website: https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-src.tar.bz2
and have this be package dependency to single package gcc and newlib, until we deprecate that one also. Or third solution is to have this built, packaged and published just as single package.
I will try to publish yml files and eopkg files on my public github repo when i find some free time, so you can have a look at those and see if it's feasible to include them in Solus like this.
Just a side note, i need this toolchain to build QMK firmware for my custom keyboard, so it would be really nice if we can have it in Solus repo, together with AVR toolchain (which i also managed to package and i will open new issue for that one) because there are some keyboards that use AVR based microcontrollers (Atmel), and some that uses ARM based microcontrollers (STM32). I tested these packages by building QMK firmware (for both ARM based and AVR based keyboards) and it works.