[oe] BBCLASSEXTEND sdk vs. nativesdk
Scott Garman
sgarman at zenlinux.com
Wed Mar 24 06:42:08 UTC 2010
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
More information about the Openembedded-devel
mailing list