Built OpenWrt with Linaro GCC (ARM)

I've working in a custom build of OpenWrt for my router, which runs in a Qualcomm IPQ4018 CPU (Quad core, Cortex A7). I've successfully built and tested (in a long run, more than 30 days and counting without a crash) the whole OpenWrt (from the kernel to all packages) using the Linaro 7.4.1 toolchain.

I have no problems either with the development nor with the running image, but my question is: is it worth? Would OpenWrt want to merge my changes for building OpenWrt with Linaro GCC?

Is the resulting kernel and/or root file system notably smaller?

Are there measurable, significant changes in performance? (For me, that means 10% or more.)

Welcome back


Disclaimer: I'm not an OpenWrt developer and can't speak for them.

Considering that OpenWrt is built for many different architectures, including ones that are not in Linaro's focus (e.g. mips, powerpc, etc.), it would need a very compelling reason to switch (as doing so would not just double, but multiply the maintenance efforts).

OpenWrt has used the Linaro toolchain in the past, but switched back to the normal GNU toolchain some time ago - which probably has its ${reasons}.

I didn’t ever mentioned a switch. OpenWrt will always build using the official GNU toolchain, just like Android.
I am suggesting about a patch for building OpenWrt with Linaro, not a patch to replace GNU with Linaro.
Some developers (such as Linksys, as I reversed engendered their firmware) use Linaro under production and having the option to do so can be good for several reasons, for example, getting the benefits of the custom Linaro toolchain for Linux (according to them, a reasonable performance boost, smaller code, energy efficiency and so on).

That's what I meant by multiplying maintenance efforts. Adding (optionally) another toolchain means having to maintain both the toolchain itself and all the architectures and packages you need to build - and this is not just a duplication of efforts (choosing between two different sets of bugs), but a multiplication once several architectures/ targets come into play, combined with a vast amount of packages in the repos; that's before even considering more finicky interactions (are packages built with GNU always 100% binary compatible with linaro, what happens if you mix (consider your own image built with linaro, but installing packages via opkg from the official repos)).

This would be a considerable amount of additional work, which would need to have good reasons (e.g. significantly less bugs/ easier cooperation with toolchain upstream, much faster code, much smaller binaries (even after xz-compression)). Going through the additional pain just needs a good justification, based on hard facts (e.g. reproducable benchmarks, image size, etc.) - and from a maintenance point of view, it's easier to switch alltogether (for all targets!), than to explode the complexity by offering another toolchain optionally.

1 Like

i don't think so. afaik, they started upstreaming all their work... so, just use the latest gcc and you're good.

If you have authority over OpenWrt choices, I encourage you to close the thread immediately and reject the idea. Else, thank you very much for your opinion but I really want an opinion about the idea from a person with authority.

Anyway, I understand your point. Don’t get me wrong if I sound edgy.

Every change, toolchain or not, can introduce edge cases and I understand that a good reason is needed.
However, the question was if it was worth. This mean that we cannot reject the idea for the sole possibility of edge cases without a real test before.
It would be like dumping a whole possibly because it can go wrong without even testing or trying.

If OpenWrt does not want it, I’ll keep the option open to any developer (i.e. people that make custom builds, particularly those that want the possibility of a more performant build) that want to try. We can discuss more and get a mature, formal request to OpenWrt in the future.

Can I know from where did you get that information?

The openwrt-devel mailing list would be the place to go for that


Linaro GCC was actually used back in the day...

What you need to keep in mind that it adds another layer of debugging when (if) things goes wrong as Linaro GCC != GNU GCC and is that really worth it? Looking at http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.4-2019.01/ChangeLog.linaro it doesn't seem like there's much of a difference to GNU GCC but I might be wrong.

1 Like