[oe] 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