Page MenuHomeSolus

Closed, ResolvedPublic

Event Timeline

BearzR created this task.Aug 31 2016, 2:04 AM

For what reason? Solus is x86_64 only.

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.

Tick added a subscriber: Tick.Sep 1 2016, 1:25 PM
DataDrake triaged this task as Normal priority.Sep 10 2016, 2:06 PM

The source downloads for the gcc-arm-none-eabi are have moved to 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:

  • arm-none-eabi-binutils
  • arm-none-eabi-gcc
  • arm-none-eabi-gdb
  • arm-none-eabi-newlib

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

JoshStrobl closed this task as Wontfix.Jun 25 2018, 1:06 PM
JoshStrobl claimed this task.
JoshStrobl added a project: Needs Maintainer.
JoshStrobl added a subscriber: JoshStrobl.

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.

chax added a subscriber: chax.Mar 22 2019, 3:31 PM

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

chax added a comment.Mar 22 2019, 8:48 PM

I made a git repo with these package definitions, here it is:
For now i didn't upload built .eopkg files.

BearzR reopened this task as Open.EditedMar 30 2019, 9:45 AM

@chax I think you needed to reopen the task as @JoshStrobl has said in his comment above.

chax added a subscriber: DataDrake.Apr 1 2019, 8:01 AM

@BearzR I still have some things to resolve before i submit patch. I talked with @DataDrake on #Solus-Dev channel on about some details, and i'm working on improvements.

@DataDrake since this issue is in the process of resolving, should I create a separate request for arm-linux-guneabihf gcc toolchain?
If you guys will figure out the correct package structure and naming scheme for these toolchains here, I will try to package arm-linux-gnueabihf based on @chax work.

chax added a comment.Apr 10 2019, 4:58 AM

Create package request and if it gets accepted for inclusion i can help you with packaging.

DataDrake reopened this task as Open.May 21 2019, 12:29 AM
DataDrake reopened this task as Open.May 21 2019, 2:36 AM