Re: Cross compiler which runs on the target architecture.

[Richard Purdie <richard.purdie@linuxfoundation.org>]

Hi,

On Sat, 2014-12-20 at 14:43 +0000, Peter Saunderson wrote:
> I have seen a brief IRC chat 
> (https://www.yoctoproject.org/irc/%23yocto.2013-09-23.log.html talking 
> about https://github.com/nathanrossi/meta-parallella) about this 
> question but nothing much else so this is an attempt to get more public 
> feedback on this request.
> 
> I am trying to build a cross compiler that runs on the target processor 
> and a cross compiler that runs on the host processor so that I can build 
> code for a third processor (Epiphany).  If you want examples of the 
> traditional way to build this compiler look at 
> https://github.com/adapteva/epiphany-sdk epiphany-gcc epiphany-newlib 
> epiphany-binutils... The end result would be a set of recipes that run 
> on a pc build machine that build both arm code for the interim target 
> and epiphany code for the final target and provides an SDK for the pc 
> that enables you to cross compile for both arm and epiphany.
> 
> As I am just starting to look at this I would like to know what size of 
> task I am up against!  My initial efforts based on review of 
> poky/meta/recipes-devtools/binutils etc seem to suggest that I have to 
> modify at least ${HOST_PREFIX}, ${TARGET_PREFIX}, ${TARGET_ARCH} etc for 
> my epiphany-??? recipes so that the I can install the compiler in a 
> suitable location with a suitable prefix, the IRC chat indicates that 
> there are more things to consider also.
> 
> The question I have is about how easy it will be to use existing recipes 
> for existing compiler / binutils etc... or is this likely to end up as a 
> completely new set of recipes from the ground up because the existing 
> recipes cant cope with building cross / cross compilers where there are 
> three processors to consider (host (intel based pc), interim target 
> (arm) and final target (epiphany)), or at least a lot of changes in the 
> existing recipes to cope with something like TARGET_TARGET_ARCH = 
> ${TARGET_ARCH}_${FINAL_TARGET_ARCH}??

Funnily enough I've a similar need to do something like this for a
personal project but targeting AVR.

Certainly OE has the power and capability to do something like this, I'm
not sure its straightforward though, at least generically, and I say
that as one of the people with pretty intimate knowledge of the
toolchain recipes.

The easy parts are creating recipes for binutils and gcc to run on the
target, targeting a third arch. This is like cross-canadian but built to
run on MACHINE instead of SDKMACHINE and taretting a new arch (probably
'target-cross-canadian'). The massively harder part is the libc for gcc
to build against and any other libs for the system.

The issue is that bitbake.conf locks the choice of MACHINE early in the
configuration stage. We added SDKMACHINE as a way of letting us build
SDKs and we have multilib and BBCLASSEXTEND but these all only target a
single arch.

Part of me tries to ensure whatever solution we come up with can scale.
This means I'd like my arm target to be able to build compilers
targetting x86, mips and ppc as well as arm, all in one build. The
question then comes to libc and whether you'd rebuild libc each time,
whether you'd reuse the same libc package as a standard build or whether
you'd have a special version of the libc for the 'target-cross-canadian'
toolchain.

Stepping back from that craziness, I suspect some specialist recipes for
avr/epiphany would probably be easiest right now, albeit less
satisfying.

Cheers,

Richard