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
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
