Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie <rpurdie@rpsys.net>]

On Tue, 2010-03-23 at 23:42 -0700, Scott Garman wrote:
> On 03/23/2010 10:45 PM, Khem Raj wrote:
> >> It seems to me the correct course of action is to use nativesdk in
> >> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
> >
> > you should rename the dependencies on zlib-sdk to zlib-nativesdk
> > wherever they exist.

This isn't quite correct. nativesdk is not a drop in replacement for the
old sdk but you are right that is is the replacement.

The difference is that the old "sdk" assumes the system you want the sdk
to run on is the same as the build system. This has always been a big
can of worms causing problems so "nativesdk" removes this assumption and
allows you to set SDKMACHINE to be the machine you want the resulting
sdk to run on.

This adds some complexity since we need another cross compiling
toolchain. But cross compiling toolchains are something we're good
at :). It also means we ship *everything* with the sdk including a
standalone glibc massively removing system dependencies from the result
which in my opinion can only be a good thing.

"sdk" and "nativesdk" are designed to coexist and the idea is that we
add "nativesdk" to OE alongside "sdk", get it working, then remove the
old broken "sdk" stuff.

In theory you can therefore just add the BBCLASSEXTEND line to the zlib
recipe and work backwards from there. You will need a working -crosssdk
version of gcc to provide the different compiler.

> I am running into some problems now trying to get zlib-nativesdk to 
> build. If I change the recipe to use sdk, it builds fine, so I have 
> something useful to compare things to.
> 
> When I build using nativesdk, configure dies pretty quickly when testing 
> the compiler. It's trying to run i686-linux-gcc.
> 
> Sure enough, if I compare the BitBake environments using the -e option, 
> I see that CC is being set to "gcc" when I use sdk but "i686-linux-gcc" 
> when I use nativesdk.
> 
> If I create the needed symlink to gcc, the compilation gets further but 
> still fails, wanting i686-linux-ar, etc. So I have a basic understanding 
> of what the problem is, but I'm sure the solution is not to go symlink 
> crazy with my native compiler environment.

See above, its missing the -crosssdk cross compiler. Did you not have to
ASSUME_PROVIDED something to make the dependencies work?

> So I took a look at sdk.bbclass and nativesdk.bbclass. They both set up 
> a number of architecture-specific variables, but neither of them 
> explicitly set CC. Where I should look next?
> 
> It turns out there is only one package currently in OE that uses 
> BBCLASSEXTEND with nativesdk (gettext_0.17). So perhaps it is the case 
> that nativesdk.bbclass needs additional work. I did test copying over 
> Poky's nativesdk.bbclass (which has just a few differences), but I still 
> get the same results.

We probably need those differences in OE. Its nice to see someone
looking at this!

Cheers,

Richard