On 11/11/2009 02:29 PM, Chris Conroy wrote:
On Wed, 2009-11-11 at 14:07 -0700, Gary Thomas wrote:

Thanks for the pointer.  Given that I'm really new with OE, can you
give me a clue as to how to use that recipe?  Can I just add some
magic to my local.conf to make this work (instead of the lines quoted above)?


Sure thing. Sadly the snapshot of OE that we're working with internally
had some issues which required us to pull a few changes from poky and
make some local changes which I haven't been able to push upstream yet.
Long story short, I'm not 100% in sync with trunk here so you may need
to change a couple of things, but this will get you most of the way
there. Most of my issues were in the creation, not in the sourcing of
the toolchain.

We allow developers to choose between an "external" or "scratch" (let OE
build it) toolchain and use a paradigm similar to the pokymode. In my
local.conf I have

TOOLCHAIN="external"

In my distro conf I have:

#Default to build the toolchain if no external one is selected
TOOLCHAIN ?= "scratch"
require conf/toolchain-${TOOLCHAIN}.conf

My toolchain-external.conf looks like:
PREFERRED_PROVIDER_linux-libc-headers = "external-toolchain"
PREFERRED_PROVIDER_glibc-thread-db = "external-toolchain"
PREFERRED_PROVIDER_libstdc++-dev = "external-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = "external-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "external-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial = "external-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate =  
"external-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = "external-toolchain"
PREFERRED_PROVIDER_virtual/binutils = "external-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc =  "external-toolchain"
PREFERRED_PROVIDER_virtual/libc =  "external-toolchain"
PREFERRED_PROVIDER_virtual/libintl =  "external-toolchain"
PREFERRED_PROVIDER_virtual/libiconv =  "external-toolchain"


TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_HOST}"
PATH =. "${SDK_PREFIX}/bin:"

I believe the SDK_PREFIX is a pokyism. I also pulled in the BUILDSDK_CPPFLAGS 
and friends from poky.

in bitbake.conf...
export BUILDSDK_CPPFLAGS = "-isystem${STAGING_INCDIR}"
export BUILDSDK_CFLAGS = "${BUILDSDK_CPPFLAGS} ${BUILD_OPTIMIZATION}"
export BUILDSDK_LDFLAGS = "-L${STAGING_LIBDIR} \
                     -Wl,-rpath-link,${STAGING_LIBDIR} \
                     -Wl,-rpath,${libdir} -Wl,-O1"

in sdk.bbclass...
CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
CFLAGS = "${BUILDSDK_CFLAGS}"
CXXFLAGS = "${BUILDSDK_CFLAGS}"
LDFLAGS = "${BUILDSDK_LDFLAGS}"


Hopefully that helps. Ideally this stuff would just work out of the box, but it 
sounds like the toolchain setup is going to get a major makeover soon.

I've tried this setup and it _almost_ works.  I still have
a problem though in that it insists on building gcc-cross
(which is failing for some reason).

I can't figure out why gcc-cross is required, nor how to
override/remove this dependency.

Any ideas?

Thanks


--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

Reply via email to