sdk.bbclass and gcc-cross-sdk

sdk.bbclass and gcc-cross-sdk

[Richard Purdie]

I've been banging my head against a wall with the rather strange things
gcc-cross-sdk is doing in OE.dev. I will write down my thoughts since I
will forget and others may find this useful in future.

I think most of the problem comes from people having different
expectations from the sdk classes. Our current sdk class is really a
"cross-sdk" and is not suitable for building sdk packages. What's the
difference?

qemu is a good example of an sdk package, it runs in /usr/local/foo/...
but doesn't have anything to do with the target.

gcc-cross-sdk is a good example of a "cross-sdk" package since it runs
in /usr/local/foo/... but is target specific.

When we build gcc-cross, our build triplet is made to equal the host
triplet. In this configuration, gcc takes a shortcut and uses its own
internal compiler to do the compiling (xgcc). If build != host, we're
into the situation where we have a Canadian cross and we need a separate
cross compiler. If gcc-cross is in staging already, we have this and it
does work but it is a fundamental change in behaviour to who things were
'designed'.

One of the changes I made to sdk.bbclass was to make the HOST_VENDOR =
TARGET_VENDOR to avoid problems with pollution of native staging when
building things like qemu-sdk and its dependencies. This meant that
build != host and caused the above problem. gcc-cross is not depended on
by gcc-cross-sdk but would work if it was present in staging. OE.dev is
therefore working from some people but since the dependencies aren't
setup to ensure gcc-cross builds first, it doesn't work for everyone.

gcc is filled with "build == host" checks. When that is the case it
makes assumptions which turn out to be dangerous since it assumes that
it can look in exec_prefix for things. Using build == host for
gcc-cross-sdk therefore makes me very nervous as whilst it works, its
likely to break

I don't doubt the usefulness of being able generate standalone compilers
with OE and the ability to add tools like pkgconfig and qemu to them.
Poky and its SDK has already shown how well these can work and its
hacked sdk class does remarkably well. 

I have to wonder how we should generate things properly though.
Currently our SDK approach can only generate SDK tools which will run on
the same architecture as it was built on. If we go for the Canadian
cross approach we should be able to support building an SDK for a
different arch (e.g. build i686 on x86_64 and vice versa). You then
start to wonder if there shouldn't be a machine/distro to do this
instead since its cross compiling although the idea doesn't quite fit.
You then start to wonder about automating sdk/native/whatever flavours
of packages at the bitbake level too.

There are also some other issues to do with ARCH_FLAGS_FOR_TARGET but I
won't complicate this with them.

What do I propose as a solution? I think the simplest thing is to would
be to do some/all of:

a) revert my sdk.bbclass changes
b) continue with our build == host assumption for gcc-cross-sdk for now
c) rename sdk.bbclass cross-sdk.bbclass
d) add a "real" sdk.bbclass

These aren't major changes, shouldn't cause much "fallout" and means OE
could still have Poky style sdk tool generation. We need to give the
whole thing some careful thought beyond this though...

Cheers,

Richard

Re: sdk.bbclass and gcc-cross-sdk

[Leon Woestenberg]

Richard,

On Wed, Mar 5, 2008 at 7:11 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>  What do I propose as a solution? I think the simplest thing is to would
>  be to do some/all of:
>
>  a) revert my sdk.bbclass changes
>  b) continue with our build == host assumption for gcc-cross-sdk for now
>  c) rename sdk.bbclass cross-sdk.bbclass
>  d) add a "real" sdk.bbclass
>
Before a), I would like to see a description of what we expect the
different classes to do, simply because I have lost track. I
understood we never  supported building Canadian cross-compilers, BTW.

There are other projects that focus on the correctness of building
cross toolchains*, canadian or non-canadian, and if we have clear
requirements for each of our classes, I would like to see if I can
understand what we do (correctly or not).

Regards,

Leon.

*diy-linux.org is the most pedantic about correctness in the toolchain
bootstrap, AFAIK.

Regards,
-- 
Leon

Re: sdk.bbclass and gcc-cross-sdk

[Richard Purdie]

On Wed, 2008-03-05 at 20:06 +0100, Leon Woestenberg wrote:
> On Wed, Mar 5, 2008 at 7:11 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> >  What do I propose as a solution? I think the simplest thing is to would
> >  be to do some/all of:
> >
> >  a) revert my sdk.bbclass changes
> >  b) continue with our build == host assumption for gcc-cross-sdk for now
> >  c) rename sdk.bbclass cross-sdk.bbclass
> >  d) add a "real" sdk.bbclass
> >
> Before a), I would like to see a description of what we expect the
> different classes to do, simply because I have lost track. I
> understood we never  supported building Canadian cross-compilers, BTW.

The 'normal' situation for OE is:

  build = "build system"
  host = target = "set by machine config"

cross.bbclass: 

  build = host = "build system"
  target = "set by machine config"

native.bbclass:

  build = host = target = "build system"

sdk.bbclass (previously)

  build = host = "build system"
  target = "set by machine config"

sdk.bbclass (previously)

  build = "build system"
  host = "build system with modified vendor"
  target = "set by machine config"

> There are other projects that focus on the correctness of building
> cross toolchains*, canadian or non-canadian, and if we have clear
> requirements for each of our classes, I would like to see if I can
> understand what we do (correctly or not).

So sdk.bbclass did become a kind of Canadian cross but only with a
different vendor part of the triplet. I'd not realised this had changed
what gcc-cross-sdk was doing so drastically since it still worked!

"gcc" is a normal package, "gcc-initial" and "gcc-cross" are cross
packages, gcc-cross-sdk is an sdk package.

We could support building canadian cross if we wanted, Id propose a new
class for it though (sdk-canadian?). Does that cover what you wanted?

Cheers,

Richard

Re: sdk.bbclass and gcc-cross-sdk

[Leon Woestenberg]

Hello Richard,

On Wed, Mar 5, 2008 at 9:24 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Wed, 2008-03-05 at 20:06 +0100, Leon Woestenberg wrote:
>  > On Wed, Mar 5, 2008 at 7:11 PM, Richard Purdie <rpurdie@rpsys.net> wrote:


>
>  The 'normal' situation for OE is:
>
>   build = "build system"
>   host = target = "set by machine config"
>
>  cross.bbclass:
>
>   build = host = "build system"
>   target = "set by machine config"
>
>  native.bbclass:
>
>   build = host = target = "build system"
>
>  sdk.bbclass (previously)
>
>   build = host = "build system"
>   target = "set by machine config"
>
>  sdk.bbclass (previously)
>
>   build = "build system"
>   host = "build system with modified vendor"
>   target = "set by machine config"
>
OK, so you meant that this last instance in fact was a Canadian cross
toolchain?

> Does that cover what you wanted?
>
Your answers covered my questions, thanks!

I don't need a Canadian cross toolchain myself, btw.

Regards,
-- 
Leon

Re: sdk.bbclass and gcc-cross-sdk

[Richard Purdie]

On Thu, 2008-03-06 at 23:58 +0100, Leon Woestenberg wrote:
> On Wed, Mar 5, 2008 at 9:24 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> >  sdk.bbclass (previously)
> >
> >   build = "build system"
> >   host = "build system with modified vendor"
> >   target = "set by machine config"
> >
> OK, so you meant that this last instance in fact was a Canadian cross
> toolchain?

Yes, it had turned into one but that wasn't the intent.

Cheers,

Richard

Re: sdk.bbclass and gcc-cross-sdk

[Esben Haabendal]

Richard Purdie skrev:
> On Wed, 2008-03-05 at 20:06 +0100, Leon Woestenberg wrote:
>   
>> On Wed, Mar 5, 2008 at 7:11 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>>     
>>>  What do I propose as a solution? I think the simplest thing is to would
>>>  be to do some/all of:
>>>
>>>  a) revert my sdk.bbclass changes
>>>  b) continue with our build == host assumption for gcc-cross-sdk for now
>>>  c) rename sdk.bbclass cross-sdk.bbclass
>>>  d) add a "real" sdk.bbclass
>>>
>>>       
>> Before a), I would like to see a description of what we expect the
>> different classes to do, simply because I have lost track. I
>> understood we never  supported building Canadian cross-compilers, BTW.
>>     
>
> The 'normal' situation for OE is:
>
>   build = "build system"
>   host = target = "set by machine config"
>
> cross.bbclass: 
>
>   build = host = "build system"
>   target = "set by machine config"
>
> native.bbclass:
>
>   build = host = target = "build system"
>
> sdk.bbclass (previously)
>
>   build = host = "build system"
>   target = "set by machine config"
>
> sdk.bbclass (previously)
>
>   build = "build system"
>   host = "build system with modified vendor"
>   target = "set by machine config"
>
>   
>> There are other projects that focus on the correctness of building
>> cross toolchains*, canadian or non-canadian, and if we have clear
>> requirements for each of our classes, I would like to see if I can
>> understand what we do (correctly or not).
>>     
>
> So sdk.bbclass did become a kind of Canadian cross but only with a
> different vendor part of the triplet. I'd not realised this had changed
> what gcc-cross-sdk was doing so drastically since it still worked!
>
> "gcc" is a normal package, "gcc-initial" and "gcc-cross" are cross
> packages, gcc-cross-sdk is an sdk package.
>
> We could support building canadian cross if we wanted, Id propose a new
> class for it though (sdk-canadian?). Does that cover what you wanted?
>   
I would love to see canadian cross support in OE. It would save me the 
effort maintaining an OE hacked up to build a standard meta-toolchain 
target.

If there is interest in it, I wouldn't mind working on this issue.  And 
if I am the only one interested in it, I might want to do it anyway. 
Just for fun :-)

/Esben

Re: sdk.bbclass and gcc-cross-sdk

[Florian Boor]

Hi,

Esben Haabendal schrieb:

> I would love to see canadian cross support in OE. It would save me the 
> effort maintaining an OE hacked up to build a standard meta-toolchain 
> target.

that would be a good feature. It might be useful for solving a similar situation
I ran into several times: Building more compatible toolchains. This solution
could be used to build a toolchain that runs on multiple distributions without
the need to choose a particular distribution on the build machine.

> If there is interest in it, I wouldn't mind working on this issue.  And 
> if I am the only one interested in it, I might want to do it anyway. 
> Just for fun :-)

I'm quite sure that there are quite some people out there who would appreciate
this. These poor guys who have to develop for Linux devices using Windows just
come to my mind - I guess they would love to see others building shiny new
crosstoolchains for their Windows :-)

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76