Re: BBCLASSEXTEND sdk vs. nativesdk

[Scott Garman <sgarman@zenlinux.com>]

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.

Khem: Thanks for the confirmation.

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.

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.

Thanks,

Scott

-- 
Scott Garman
sgarman at zenlinux dot com