[oe] BBCLASSEXTEND sdk vs. nativesdk

[jkridner at beagleboard.org]

Is this also the mechanism for building an sdk for the target then?  Seems great to normalize this. 

If I wanted to build a MIPS cross-compiler that ran on an ARM board, and build that from an x86 machine, what would it look like given nativesdk?

Sorry for the blackberry top post. 
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Richard Purdie <rpurdie at rpsys.net>
Date: Wed, 24 Mar 2010 10:28:36 
To: <openembedded-devel at lists.openembedded.org>
Subject: Re: [oe] BBCLASSEXTEND sdk vs. nativesdk

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



_______________________________________________
Openembedded-devel mailing list
Openembedded-devel at lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel