Prebuilt toolchains

Prebuilt toolchains

[Gary Thomas]

I'd like to use my own toolchains when building OpenEmbedded.
I've tried to follow the information at:
   http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
It's a bit terse and confusing, so I'm just trying to see
what I need (I think the section tries to discuss too many
concepts at once)

Anyway, I added these lines to my local.conf:
   TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
   ASSUME_PROVIDED += " virtual/libc "

This led to a number of other inferences which I don't understand.
   NOTE: selecting glibc to satisfy virtual/libintl due to PREFERRED_PROVIDERS
   NOTE: selecting glibc to satisfy runtime libsegfault due to PREFERRED_PROVIDER_virtual/libc = glibc
   NOTE: selecting linux-libc-headers to satisfy runtime linux-libc-headers-dev due to PREFERRED_PROVIDER_linux-libc-headers = linux-libc-headers
   NOTE: selecting glibc to satisfy runtime glibc due to PREFERRED_PROVIDER_virtual/libc = glibc
   NOTE: selecting gcc-cross-intermediate to satisfy virtual/powerpc-linux-gcc-intermediate due to PREFERRED_PROVIDERS
   NOTE: selecting linux-libc-headers to satisfy linux-libc-headers due to PREFERRED_PROVIDERS
   NOTE: selecting glibc to satisfy virtual/libiconv due to PREFERRED_PROVIDERS
   NOTE: selecting gcc-cross to satisfy runtime libgcc due to PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross
   NOTE: selecting binutils-cross to satisfy virtual/powerpc-linux-binutils due to PREFERRED_PROVIDERS
   NOTE: selecting glibc-initial to satisfy virtual/powerpc-linux-libc-initial due to PREFERRED_PROVIDERS
   NOTE: selecting glibc to satisfy virtual/powerpc-linux-libc-for-gcc due to PREFERRED_PROVIDERS
   NOTE: selecting gcc-cross-initial to satisfy virtual/powerpc-linux-gcc-initial due to PREFERRED_PROVIDERS

At which point, OE goes off on its merry way to build the
internal toolchains.

What am I missing?

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

Re: Prebuilt toolchains

[Chris Conroy]

On Wed, 2009-11-11 at 10:00 -0700, Gary Thomas wrote:
> I'd like to use my own toolchains when building OpenEmbedded.
> I've tried to follow the information at:
>    http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
> It's a bit terse and confusing, so I'm just trying to see
> what I need (I think the section tries to discuss too many
> concepts at once)
> 
> Anyway, I added these lines to my local.conf:
>    TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
>    ASSUME_PROVIDED += " virtual/libc "
> 
> This led to a number of other inferences which I don't understand.
>    NOTE: selecting glibc to satisfy virtual/libintl due to PREFERRED_PROVIDERS
>    NOTE: selecting glibc to satisfy runtime libsegfault due to PREFERRED_PROVIDER_virtual/libc = glibc
>    NOTE: selecting linux-libc-headers to satisfy runtime linux-libc-headers-dev due to PREFERRED_PROVIDER_linux-libc-headers = linux-libc-headers
>    NOTE: selecting glibc to satisfy runtime glibc due to PREFERRED_PROVIDER_virtual/libc = glibc
>    NOTE: selecting gcc-cross-intermediate to satisfy virtual/powerpc-linux-gcc-intermediate due to PREFERRED_PROVIDERS
>    NOTE: selecting linux-libc-headers to satisfy linux-libc-headers due to PREFERRED_PROVIDERS
>    NOTE: selecting glibc to satisfy virtual/libiconv due to PREFERRED_PROVIDERS
>    NOTE: selecting gcc-cross to satisfy runtime libgcc due to PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross
>    NOTE: selecting binutils-cross to satisfy virtual/powerpc-linux-binutils due to PREFERRED_PROVIDERS
>    NOTE: selecting glibc-initial to satisfy virtual/powerpc-linux-libc-initial due to PREFERRED_PROVIDERS
>    NOTE: selecting glibc to satisfy virtual/powerpc-linux-libc-for-gcc due to PREFERRED_PROVIDERS
>    NOTE: selecting gcc-cross-initial to satisfy virtual/powerpc-linux-gcc-initial due to PREFERRED_PROVIDERS
> 
> At which point, OE goes off on its merry way to build the
> internal toolchains.
> 
> What am I missing?

You may want to try using the external-toolchain recipe. Though it's
mainly used for toolchains built by OE, poky has recipes for
Codesourcery toolchains which you could certainly use as a starting
point for your toolchain.

Then in your conf file you need to set the external-toolchain as the
PREFERRED_PROVIDER for everything it provides (gcc, libc, libstdc++,
binutils, etc..). I think this is a bit cleaner than doing
ASSUME_PROVIDED because it makes the use of the external toolchain a bit
more explicit.

I guess this leads me to ask the rest of the list: should the user
manual be updated to include docs on the external-toolchain recipe?

Re: Prebuilt toolchains

[Gary Thomas]

On 11/11/2009 01:39 PM, Chris Conroy wrote:
> On Wed, 2009-11-11 at 10:00 -0700, Gary Thomas wrote:
>> I'd like to use my own toolchains when building OpenEmbedded.
>> I've tried to follow the information at:
>>     http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
>> It's a bit terse and confusing, so I'm just trying to see
>> what I need (I think the section tries to discuss too many
>> concepts at once)
>>
>> Anyway, I added these lines to my local.conf:
>>     TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
>>     ASSUME_PROVIDED += " virtual/libc "
>>
>> This led to a number of other inferences which I don't understand.
>>     NOTE: selecting glibc to satisfy virtual/libintl due to PREFERRED_PROVIDERS
>>     NOTE: selecting glibc to satisfy runtime libsegfault due to PREFERRED_PROVIDER_virtual/libc = glibc
>>     NOTE: selecting linux-libc-headers to satisfy runtime linux-libc-headers-dev due to PREFERRED_PROVIDER_linux-libc-headers = linux-libc-headers
>>     NOTE: selecting glibc to satisfy runtime glibc due to PREFERRED_PROVIDER_virtual/libc = glibc
>>     NOTE: selecting gcc-cross-intermediate to satisfy virtual/powerpc-linux-gcc-intermediate due to PREFERRED_PROVIDERS
>>     NOTE: selecting linux-libc-headers to satisfy linux-libc-headers due to PREFERRED_PROVIDERS
>>     NOTE: selecting glibc to satisfy virtual/libiconv due to PREFERRED_PROVIDERS
>>     NOTE: selecting gcc-cross to satisfy runtime libgcc due to PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross
>>     NOTE: selecting binutils-cross to satisfy virtual/powerpc-linux-binutils due to PREFERRED_PROVIDERS
>>     NOTE: selecting glibc-initial to satisfy virtual/powerpc-linux-libc-initial due to PREFERRED_PROVIDERS
>>     NOTE: selecting glibc to satisfy virtual/powerpc-linux-libc-for-gcc due to PREFERRED_PROVIDERS
>>     NOTE: selecting gcc-cross-initial to satisfy virtual/powerpc-linux-gcc-initial due to PREFERRED_PROVIDERS
>>
>> At which point, OE goes off on its merry way to build the
>> internal toolchains.
>>
>> What am I missing?
>
> You may want to try using the external-toolchain recipe. Though it's
> mainly used for toolchains built by OE, poky has recipes for
> Codesourcery toolchains which you could certainly use as a starting
> point for your toolchain.
>
> Then in your conf file you need to set the external-toolchain as the
> PREFERRED_PROVIDER for everything it provides (gcc, libc, libstdc++,
> binutils, etc..). I think this is a bit cleaner than doing
> ASSUME_PROVIDED because it makes the use of the external toolchain a bit
> more explicit.

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)?

>
> I guess this leads me to ask the rest of the list: should the user
> manual be updated to include docs on the external-toolchain recipe?
>

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

Re: Prebuilt toolchains

[Chris Conroy]

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.

--Chris Conroy

Re: Prebuilt toolchains

[Gary Thomas]

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
------------------------------------------------------------

Re: Prebuilt toolchains

[Chris Conroy]

On Fri, 2009-11-13 at 07:06 -0700, Gary Thomas wrote:
> 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?

I'd say definitely take a look at the dependency graph of whatever is
trying to build gcc-cross (bitbake -g <package>) and inspect the
depends.dot and task-depends.dot. Inspect the output of 

bitbake -n -DDD <package> | less -i

Look for gcc-cross in the output and see why it's being chosen. Looking
at my local setup, it seems that I have 

> DEBUG: sorted providers for virtual/mipsel-linux-gcc are: 
> ['/home/cconroy/p4/new_trunk/hcrest.build/packages/meta/external-toolchain.bb', 
> '/home/cconroy/p4/new_trunk/hcrest.build/packages/gcc/gcc-cross_4.2.3.bb']

If you find you have something similar, but just in the wrong order, you
may need to pull my recently accepted bitbake patch which fixes how it
works with priorities.



Also, I found it helpful to turn the "multiple providers" state in
bitbake into a fatal error condition. I can't recall if I ran into this
problem or not, but it's possible this will help:

In your lib/bb/runqueue.py you'll see a commented fatal error:
#if error:
#	bb.msg.fatal(bb.msg.domain.RunQueue, "Corrupted metadata configuration
detected, aborting...")

If you activate that error you may find this to be the cause of your
problem. If so, you may want to make the message a bit more verbose and
dump out the offending package and providers.

Hope that helps!

--Chris

Re: Prebuilt toolchains

[Gary Thomas]

On 11/13/2009 08:57 AM, Chris Conroy wrote:
> On Fri, 2009-11-13 at 07:06 -0700, Gary Thomas wrote:
>> 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?
>
> I'd say definitely take a look at the dependency graph of whatever is
> trying to build gcc-cross (bitbake -g<package>) and inspect the
> depends.dot and task-depends.dot. Inspect the output of
>
> bitbake -n -DDD<package>  | less -i
>
> Look for gcc-cross in the output and see why it's being chosen. Looking
> at my local setup, it seems that I have
>
>> DEBUG: sorted providers for virtual/mipsel-linux-gcc are:
>> ['/home/cconroy/p4/new_trunk/hcrest.build/packages/meta/external-toolchain.bb',
>> '/home/cconroy/p4/new_trunk/hcrest.build/packages/gcc/gcc-cross_4.2.3.bb']
>
> If you find you have something similar, but just in the wrong order, you
> may need to pull my recently accepted bitbake patch which fixes how it
> works with priorities.
>

This helped me find the problem - libgcc was required by busybox and
the default provider for libgcc included gcc-cross.

I ended up with only these [few] changes to get my own toolchain to
do the job:

   #
   # Use prebuilt compiler components
   #
   TOOLCHAIN = "external"
   HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
   TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
   ASSUME_PROVIDED += " linux-libc-headers "
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-cross "
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-initial "
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-intermediate "
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}binutils "
   ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}libc-for-gcc "
   ASSUME_PROVIDED += " libgcc "
   ASSUME_PROVIDED += " virtual/libc "
   ASSUME_PROVIDED += " virtual/libintl "
   ASSUME_PROVIDED += " virtual/libiconv "
   export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
                            -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
                            -Wl,-O1"

The HOST_SYS and TARGET_SYS changes were necessary because my toolchain
is called 'powerpc-linux-XXX', not 'powerpc-oe-linux-XXX'.

I chose these changes (instead of just your advice) because I was already
down this path.  Sadly, this incantation *did* complete the build, but the
resulting file system did not import any of the "provided" libraries from
my external toolchain.  Did I miss something that would let the build
import these libraries?

Finally, in an effort to explore and understand more, I tried your method:
   #
   # Use prebuilt compiler components
   #
   TOOLCHAIN = "external"
   HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
   TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
   export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
                            -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
                            -Wl,-O1"
   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"

Which led to these errors right away:
   ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers
   (['/local/Angstrom_BeagleBoard  /openembedded/recipes/glibc/glibc_2.6.1.bb',
   '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb']) for runtime dependecy libsegfault
   The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/libc = glibc', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
   ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers
   (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
   '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb']) for runtime dependecy libgcc
   The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']



>
> Also, I found it helpful to turn the "multiple providers" state in
> bitbake into a fatal error condition. I can't recall if I ran into this
> problem or not, but it's possible this will help:
>
> In your lib/bb/runqueue.py you'll see a commented fatal error:
> #if error:
> #	bb.msg.fatal(bb.msg.domain.RunQueue, "Corrupted metadata configuration
> detected, aborting...")
>
> If you activate that error you may find this to be the cause of your
> problem. If so, you may want to make the message a bit more verbose and
> dump out the offending package and providers.
>
> Hope that helps!

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

Re: Prebuilt toolchains

[Chris Conroy]

On Fri, 2009-11-13 at 10:25 -0700, Gary Thomas wrote:
> This helped me find the problem - libgcc was required by busybox and
> the default provider for libgcc included gcc-cross.
> 
> I ended up with only these [few] changes to get my own toolchain to
> do the job:
> 
>    #
>    # Use prebuilt compiler components
>    #
>    TOOLCHAIN = "external"
>    HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>    TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>    ASSUME_PROVIDED += " linux-libc-headers "
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-cross "
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-initial "
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-intermediate "
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}binutils "
>    ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}libc-for-gcc "
>    ASSUME_PROVIDED += " libgcc "
>    ASSUME_PROVIDED += " virtual/libc "
>    ASSUME_PROVIDED += " virtual/libintl "
>    ASSUME_PROVIDED += " virtual/libiconv "
>    export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>                             -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>                             -Wl,-O1"
> 
> The HOST_SYS and TARGET_SYS changes were necessary because my toolchain
> is called 'powerpc-linux-XXX', not 'powerpc-oe-linux-XXX'.
> 
> I chose these changes (instead of just your advice) because I was already
> down this path.  Sadly, this incantation *did* complete the build, but the
> resulting file system did not import any of the "provided" libraries from
> my external toolchain.  Did I miss something that would let the build
> import these libraries?

Yeah, this is the problem with ASSUME_PROVIDED as I see it. It removes
the build system knowledge of these things and basically gives the
responsibility for managing them back to you. Not good.

> 
> Finally, in an effort to explore and understand more, I tried your method:
>    #
>    # Use prebuilt compiler components
>    #
>    TOOLCHAIN = "external"
>    HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>    TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>    export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>                             -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>                             -Wl,-O1"
>    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"
> 
> Which led to these errors right away:
>    ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers
>    (['/local/Angstrom_BeagleBoard  /openembedded/recipes/glibc/glibc_2.6.1.bb',
>    '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb']) for runtime dependecy libsegfault
>    The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/libc = glibc', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>    ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers
>    (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
>    '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb']) for runtime dependecy libgcc
>    The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
> 

You may need to edit the RPROVIDES of your toolchain. Here's what mine
looks like:

RPROVIDES = " glibc-dbg glibc catchsegv sln nscd ldd localedef
glibc-utils glibc-dev glibc-locale libsegfault glibc-extra-nss
glibc-thread-db glibc-pcprofile \
              libgcc libgcc-dev libstdc++-dev libstdc++"
PACKAGES_DYNAMIC = "glibc-gconv-*"
INHIBIT_DEFAULT_DEPS = "1"

Re: Prebuilt toolchains

[Gary Thomas]

On 11/13/2009 11:41 AM, Chris Conroy wrote:
> On Fri, 2009-11-13 at 10:25 -0700, Gary Thomas wrote:
>> This helped me find the problem - libgcc was required by busybox and
>> the default provider for libgcc included gcc-cross.
>>
>> I ended up with only these [few] changes to get my own toolchain to
>> do the job:
>>
>>     #
>>     # Use prebuilt compiler components
>>     #
>>     TOOLCHAIN = "external"
>>     HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>     TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>     ASSUME_PROVIDED += " linux-libc-headers "
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-cross "
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-initial "
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-intermediate "
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}binutils "
>>     ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}libc-for-gcc "
>>     ASSUME_PROVIDED += " libgcc "
>>     ASSUME_PROVIDED += " virtual/libc "
>>     ASSUME_PROVIDED += " virtual/libintl "
>>     ASSUME_PROVIDED += " virtual/libiconv "
>>     export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>>                              -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>>                              -Wl,-O1"
>>
>> The HOST_SYS and TARGET_SYS changes were necessary because my toolchain
>> is called 'powerpc-linux-XXX', not 'powerpc-oe-linux-XXX'.
>>
>> I chose these changes (instead of just your advice) because I was already
>> down this path.  Sadly, this incantation *did* complete the build, but the
>> resulting file system did not import any of the "provided" libraries from
>> my external toolchain.  Did I miss something that would let the build
>> import these libraries?
>
> Yeah, this is the problem with ASSUME_PROVIDED as I see it. It removes
> the build system knowledge of these things and basically gives the
> responsibility for managing them back to you. Not good.
>
>>
>> Finally, in an effort to explore and understand more, I tried your method:
>>     #
>>     # Use prebuilt compiler components
>>     #
>>     TOOLCHAIN = "external"
>>     HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>     TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>     export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>>                              -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>>                              -Wl,-O1"
>>     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"
>>
>> Which led to these errors right away:
>>     ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers
>>     (['/local/Angstrom_BeagleBoard  /openembedded/recipes/glibc/glibc_2.6.1.bb',
>>     '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb']) for runtime dependecy libsegfault
>>     The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/libc = glibc', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>>     ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers
>>     (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
>>     '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb']) for runtime dependecy libgcc
>>     The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>>
>
> You may need to edit the RPROVIDES of your toolchain. Here's what mine
> looks like:
>
> RPROVIDES = " glibc-dbg glibc catchsegv sln nscd ldd localedef
> glibc-utils glibc-dev glibc-locale libsegfault glibc-extra-nss
> glibc-thread-db glibc-pcprofile \
>                libgcc libgcc-dev libstdc++-dev libstdc++"
> PACKAGES_DYNAMIC = "glibc-gconv-*"
> INHIBIT_DEFAULT_DEPS = "1"

Still no joy, I'm afraid.  I now get a *huge* series of messages like these:

NOTE: preferred version 2.11.4.1 of xf86-video-geode not available (for item libsegfault)
NOTE: preferred version 1.0.1 of font-screen-cyrillic not available (for item libsegfault)
NOTE: preferred version 1.2.4 of opie-securityplugin-dummy not available (for item libsegfault)
NOTE: preferred version 6.9.0 of xf86-video-ati not available (for item libsegfault)
NOTE: preferred version 12.5.1 of xf86-input-vmmouse not available (for item libsegfault)
ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted in an attempt to select multiple providers 
(['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxpm_3.5.7.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libice_1.0.4.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxrandr_1.2.3.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxfixes_4.0.3.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxinerama_1.0.3.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/libqpe/libqpe-opie_1.2.4.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libx11_1.1.5.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-proto/xproto_7.0.13.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxt_1.0.5.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxv_1.0.4.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxcursor_1.1.9.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxrender_0.9.4.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-xserver/xserver-xorg_1.5.3.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross-intermediate_4.4.2.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxext_1.0.4.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxi_1.2.0.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxmu_1.0.4.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/glibc/glibc_2.6.1.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/binutils/binutils-cross_2.20.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/glibc/glibc-initial_2.6.1.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxcomposite_0.4.0.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libsm_1.1.0.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxft_2.1.13.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross-initial_4.4.2.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-app/xrandr_1.2.3.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxaw_1.0.4.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxxf86vm_1.0.2.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/qte/qte-mt_2.3.10.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxdamage_1.1.1.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/linux-libc-headers/linux-libc-headers_2.6.23.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/gnome/gconf-dbus_svn.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/avahi/avahi_0.6.24.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/libgpewidget/libgpewidget_0.117.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/libsdl/libsdl-x11_1.2.11.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/linux/linux_2.6.31.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/gtk+/gtk+_2.14.2.bb', 
'/local/Angstrom_BeagleBoard/openembedded/recipes/libusb/libusb_0.1.12.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/db/db3_3.2.9.bb']) for runtime dependecy libsegfault
The entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross', 'PREFERRED_PROVIDER_libxpm = libxpm', 'PREFERRED_PROVIDER_libice = 
libice', 'PREFERRED_PROVIDER_libxrandr = libxrandr', 'PREFERRED_PROVIDER_libxfixes = libxfixes', 'PREFERRED_PROVIDER_libxinerama = libxinerama', 'PREFERRED_PROVIDER_virtual/libqpe1 
= libqpe-opie', 'PREFERRED_PROVIDER_virtual/libx11 = libx11', 'PREFERRED_PROVIDER_xproto = xproto', 'PREFERRED_PROVIDER_libxt = libxt', 'PREFERRED_PROVIDER_libxv = libxv', 
'PREFERRED_PROVIDER_libxcursor = libxcursor', 'PREFERRED_PROVIDER_libxrender = libxrender', 'PREFERRED_PROVIDER_virtual/xserver = xserver-xorg', 
'PREFERRED_PROVIDER_virtual/powerpc-linux-gcc-intermediate = gcc-cross-intermediate', 'PREFERRED_PROVIDER_libxext = libxext', 'PREFERRED_PROVIDER_libxi = libxi', 
'PREFERRED_PROVIDER_libxmu = libxmu', 'PREFERRED_PROVIDER_virtual/libc = glibc', 'PREFERRED_PROVIDER_virtual/powerpc-linux-binutils = binutils-cross', 
'PREFERRED_PROVIDER_virtual/powerpc-linux-libc-initial = glibc-initial', 'PREFERRED_PROVIDER_libxcomposite = libxcomposite', 'PREFERRED_PROVIDER_libsm = libsm', 
'PREFERRED_PROVIDER_libxft = libxft', 'PREFERRED_PROVIDER_virtual/powerpc-linux-gcc-initial = gcc-cross-initial', 'PREFERRED_PROVIDER_xrandr = xrandr', 'PREFERRED_PROVIDER_libxaw = 
libxaw', 'PREFERRED_PROVIDER_libxxf86vm = libxxf86vm', 'PREFERRED_PROVIDER_virtual/libqte2 = qte-mt', 'PREFERRED_PROVIDER_libxdamage = libxdamage', 
'PREFERRED_PROVIDER_linux-libc-headers = linux-libc-headers', 'PREFERRED_PROVIDER_gconf = gconf-dbus', 'PREFERRED_PROVIDER_avahi = avahi', 'PREFERRED_PROVIDER_libgpewidget = 
libgpewidget', 'PREFERRED_PROVIDER_virtual/libsdl = libsdl-x11', 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain', 'PREFERRED_PROVIDER_virtual/kernel = linux', 
'PREFERRED_PROVIDER_gtk+ = gtk+', 'PREFERRED_PROVIDER_virtual/libusb0 = libusb', 'PREFERRED_PROVIDER_virtual/db = db3']

Why is this so hard??  I just want to use the tools I already
have (and my customers are comfortable with)!

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

Re: Prebuilt toolchains

[Gary Thomas]

On 11/13/2009 04:00 PM, Gary Thomas wrote:
> On 11/13/2009 11:41 AM, Chris Conroy wrote:
>> On Fri, 2009-11-13 at 10:25 -0700, Gary Thomas wrote:
>>> This helped me find the problem - libgcc was required by busybox and
>>> the default provider for libgcc included gcc-cross.
>>>
>>> I ended up with only these [few] changes to get my own toolchain to
>>> do the job:
>>>
>>> #
>>> # Use prebuilt compiler components
>>> #
>>> TOOLCHAIN = "external"
>>> HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>> TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>> ASSUME_PROVIDED += " linux-libc-headers "
>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-cross "
>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-initial "
>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-intermediate "
>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}binutils "
>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}libc-for-gcc "
>>> ASSUME_PROVIDED += " libgcc "
>>> ASSUME_PROVIDED += " virtual/libc "
>>> ASSUME_PROVIDED += " virtual/libintl "
>>> ASSUME_PROVIDED += " virtual/libiconv "
>>> export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>>> -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>>> -Wl,-O1"
>>>
>>> The HOST_SYS and TARGET_SYS changes were necessary because my toolchain
>>> is called 'powerpc-linux-XXX', not 'powerpc-oe-linux-XXX'.
>>>
>>> I chose these changes (instead of just your advice) because I was
>>> already
>>> down this path. Sadly, this incantation *did* complete the build, but
>>> the
>>> resulting file system did not import any of the "provided" libraries
>>> from
>>> my external toolchain. Did I miss something that would let the build
>>> import these libraries?
>>
>> Yeah, this is the problem with ASSUME_PROVIDED as I see it. It removes
>> the build system knowledge of these things and basically gives the
>> responsibility for managing them back to you. Not good.
>>
>>>
>>> Finally, in an effort to explore and understand more, I tried your
>>> method:
>>> #
>>> # Use prebuilt compiler components
>>> #
>>> TOOLCHAIN = "external"
>>> HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>> TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>> export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>>> -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>>> -Wl,-O1"
>>> 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"
>>>
>>> Which led to these errors right away:
>>> ERROR: Conflicting PREFERRED_PROVIDER entries were found which
>>> resulted in an attempt to select multiple providers
>>> (['/local/Angstrom_BeagleBoard
>>> /openembedded/recipes/glibc/glibc_2.6.1.bb',
>>> '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb'])
>>> for runtime dependecy libsegfault
>>> The entries resulting in this conflict were:
>>> ['PREFERRED_PROVIDER_virtual/libc = glibc',
>>> 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>>> ERROR: Conflicting PREFERRED_PROVIDER entries were found which
>>> resulted in an attempt to select multiple providers
>>> (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
>>>
>>> '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb'])
>>> for runtime dependecy libgcc
>>> The entries resulting in this conflict were:
>>> ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross',
>>> 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>>>
>>
>> You may need to edit the RPROVIDES of your toolchain. Here's what mine
>> looks like:
>>
>> RPROVIDES = " glibc-dbg glibc catchsegv sln nscd ldd localedef
>> glibc-utils glibc-dev glibc-locale libsegfault glibc-extra-nss
>> glibc-thread-db glibc-pcprofile \
>> libgcc libgcc-dev libstdc++-dev libstdc++"
>> PACKAGES_DYNAMIC = "glibc-gconv-*"
>> INHIBIT_DEFAULT_DEPS = "1"
>
> Still no joy, I'm afraid. I now get a *huge* series of messages like these:
>
> NOTE: preferred version 2.11.4.1 of xf86-video-geode not available (for
> item libsegfault)
> NOTE: preferred version 1.0.1 of font-screen-cyrillic not available (for
> item libsegfault)
> NOTE: preferred version 1.2.4 of opie-securityplugin-dummy not available
> (for item libsegfault)
> NOTE: preferred version 6.9.0 of xf86-video-ati not available (for item
> libsegfault)
> NOTE: preferred version 12.5.1 of xf86-input-vmmouse not available (for
> item libsegfault)
> ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted
> in an attempt to select multiple providers
> (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxpm_3.5.7.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libice_1.0.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxrandr_1.2.3.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxfixes_4.0.3.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxinerama_1.0.3.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/libqpe/libqpe-opie_1.2.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libx11_1.1.5.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-proto/xproto_7.0.13.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxt_1.0.5.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxv_1.0.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxcursor_1.1.9.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxrender_0.9.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-xserver/xserver-xorg_1.5.3.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross-intermediate_4.4.2.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxext_1.0.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxi_1.2.0.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxmu_1.0.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/glibc/glibc_2.6.1.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/binutils/binutils-cross_2.20.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/glibc/glibc-initial_2.6.1.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxcomposite_0.4.0.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libsm_1.1.0.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxft_2.1.13.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross-initial_4.4.2.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-app/xrandr_1.2.3.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxaw_1.0.4.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxxf86vm_1.0.2.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/qte/qte-mt_2.3.10.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxdamage_1.1.1.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/linux-libc-headers/linux-libc-headers_2.6.23.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/gnome/gconf-dbus_svn.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/avahi/avahi_0.6.24.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/libgpewidget/libgpewidget_0.117.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/libsdl/libsdl-x11_1.2.11.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/linux/linux_2.6.31.bb', '/local/Angstrom_BeagleBoard/openembedded/recipes/gtk+/gtk+_2.14.2.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/libusb/libusb_0.1.12.bb',
> '/local/Angstrom_BeagleBoard/openembedded/recipes/db/db3_3.2.9.bb']) for
> runtime dependecy libsegfault
> The entries resulting in this conflict were:
> ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross',
> 'PREFERRED_PROVIDER_libxpm = libxpm', 'PREFERRED_PROVIDER_libice =
> libice', 'PREFERRED_PROVIDER_libxrandr = libxrandr',
> 'PREFERRED_PROVIDER_libxfixes = libxfixes',
> 'PREFERRED_PROVIDER_libxinerama = libxinerama',
> 'PREFERRED_PROVIDER_virtual/libqpe1 = libqpe-opie',
> 'PREFERRED_PROVIDER_virtual/libx11 = libx11', 'PREFERRED_PROVIDER_xproto
> = xproto', 'PREFERRED_PROVIDER_libxt = libxt', 'PREFERRED_PROVIDER_libxv
> = libxv', 'PREFERRED_PROVIDER_libxcursor = libxcursor',
> 'PREFERRED_PROVIDER_libxrender = libxrender',
> 'PREFERRED_PROVIDER_virtual/xserver = xserver-xorg',
> 'PREFERRED_PROVIDER_virtual/powerpc-linux-gcc-intermediate =
> gcc-cross-intermediate', 'PREFERRED_PROVIDER_libxext = libxext',
> 'PREFERRED_PROVIDER_libxi = libxi', 'PREFERRED_PROVIDER_libxmu =
> libxmu', 'PREFERRED_PROVIDER_virtual/libc = glibc',
> 'PREFERRED_PROVIDER_virtual/powerpc-linux-binutils = binutils-cross',
> 'PREFERRED_PROVIDER_virtual/powerpc-linux-libc-initial = glibc-initial',
> 'PREFERRED_PROVIDER_libxcomposite = libxcomposite',
> 'PREFERRED_PROVIDER_libsm = libsm', 'PREFERRED_PROVIDER_libxft =
> libxft', 'PREFERRED_PROVIDER_virtual/powerpc-linux-gcc-initial =
> gcc-cross-initial', 'PREFERRED_PROVIDER_xrandr = xrandr',
> 'PREFERRED_PROVIDER_libxaw = libxaw', 'PREFERRED_PROVIDER_libxxf86vm =
> libxxf86vm', 'PREFERRED_PROVIDER_virtual/libqte2 = qte-mt',
> 'PREFERRED_PROVIDER_libxdamage = libxdamage',
> 'PREFERRED_PROVIDER_linux-libc-headers = linux-libc-headers',
> 'PREFERRED_PROVIDER_gconf = gconf-dbus', 'PREFERRED_PROVIDER_avahi =
> avahi', 'PREFERRED_PROVIDER_libgpewidget = libgpewidget',
> 'PREFERRED_PROVIDER_virtual/libsdl = libsdl-x11',
> 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain',
> 'PREFERRED_PROVIDER_virtual/kernel = linux', 'PREFERRED_PROVIDER_gtk+ =
> gtk+', 'PREFERRED_PROVIDER_virtual/libusb0 = libusb',
> 'PREFERRED_PROVIDER_virtual/db = db3']
>
> Why is this so hard?? I just want to use the tools I already
> have (and my customers are comfortable with)!
>

Any ideas how I can move forward with this?

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

Re: Prebuilt toolchains

[Mike Turquette]

On Mon, Nov 16, 2009 at 4:40 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 11/13/2009 04:00 PM, Gary Thomas wrote:
>>
>> On 11/13/2009 11:41 AM, Chris Conroy wrote:
>>>
>>> On Fri, 2009-11-13 at 10:25 -0700, Gary Thomas wrote:
>>>>
>>>> This helped me find the problem - libgcc was required by busybox and
>>>> the default provider for libgcc included gcc-cross.
>>>>
>>>> I ended up with only these [few] changes to get my own toolchain to
>>>> do the job:
>>>>
>>>> #
>>>> # Use prebuilt compiler components
>>>> #
>>>> TOOLCHAIN = "external"
>>>> HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>>> TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>>> ASSUME_PROVIDED += " linux-libc-headers "
>>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
>>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-cross "
>>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-initial "
>>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-intermediate "
>>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}binutils "
>>>> ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}libc-for-gcc "
>>>> ASSUME_PROVIDED += " libgcc "
>>>> ASSUME_PROVIDED += " virtual/libc "
>>>> ASSUME_PROVIDED += " virtual/libintl "
>>>> ASSUME_PROVIDED += " virtual/libiconv "
>>>> export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>>>> -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>>>> -Wl,-O1"
>>>>
>>>> The HOST_SYS and TARGET_SYS changes were necessary because my toolchain
>>>> is called 'powerpc-linux-XXX', not 'powerpc-oe-linux-XXX'.
>>>>
>>>> I chose these changes (instead of just your advice) because I was
>>>> already
>>>> down this path. Sadly, this incantation *did* complete the build, but
>>>> the
>>>> resulting file system did not import any of the "provided" libraries
>>>> from
>>>> my external toolchain. Did I miss something that would let the build
>>>> import these libraries?
>>>
>>> Yeah, this is the problem with ASSUME_PROVIDED as I see it. It removes
>>> the build system knowledge of these things and basically gives the
>>> responsibility for managing them back to you. Not good.
>>>
>>>>
>>>> Finally, in an effort to explore and understand more, I tried your
>>>> method:
>>>> #
>>>> # Use prebuilt compiler components
>>>> #
>>>> TOOLCHAIN = "external"
>>>> HOST_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>>> TARGET_SYS = "${TARGET_ARCH}-${TARGET_OS}"
>>>> export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${layout_libdir} \
>>>> -Wl,-rpath-link,${STAGING_DIR_TARGET}${layout_libdir} \
>>>> -Wl,-O1"
>>>> 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"
>>>>
>>>> Which led to these errors right away:
>>>> ERROR: Conflicting PREFERRED_PROVIDER entries were found which
>>>> resulted in an attempt to select multiple providers
>>>> (['/local/Angstrom_BeagleBoard
>>>> /openembedded/recipes/glibc/glibc_2.6.1.bb',
>>>>
>>>> '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb'])
>>>> for runtime dependecy libsegfault
>>>> The entries resulting in this conflict were:
>>>> ['PREFERRED_PROVIDER_virtual/libc = glibc',
>>>> 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>>>> ERROR: Conflicting PREFERRED_PROVIDER entries were found which
>>>> resulted in an attempt to select multiple providers
>>>>
>>>> (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
>>>>
>>>>
>>>> '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb'])
>>>> for runtime dependecy libgcc
>>>> The entries resulting in this conflict were:
>>>> ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross',
>>>> 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain']
>>>>
>>>
>>> You may need to edit the RPROVIDES of your toolchain. Here's what mine
>>> looks like:
>>>
>>> RPROVIDES = " glibc-dbg glibc catchsegv sln nscd ldd localedef
>>> glibc-utils glibc-dev glibc-locale libsegfault glibc-extra-nss
>>> glibc-thread-db glibc-pcprofile \
>>> libgcc libgcc-dev libstdc++-dev libstdc++"
>>> PACKAGES_DYNAMIC = "glibc-gconv-*"
>>> INHIBIT_DEFAULT_DEPS = "1"
>>
>> Still no joy, I'm afraid. I now get a *huge* series of messages like
>> these:
>>
>> NOTE: preferred version 2.11.4.1 of xf86-video-geode not available (for
>> item libsegfault)
>> NOTE: preferred version 1.0.1 of font-screen-cyrillic not available (for
>> item libsegfault)
>> NOTE: preferred version 1.2.4 of opie-securityplugin-dummy not available
>> (for item libsegfault)
>> NOTE: preferred version 6.9.0 of xf86-video-ati not available (for item
>> libsegfault)
>> NOTE: preferred version 12.5.1 of xf86-input-vmmouse not available (for
>> item libsegfault)
>> ERROR: Conflicting PREFERRED_PROVIDER entries were found which resulted
>> in an attempt to select multiple providers
>>
>> (['/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross_4.4.2.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxpm_3.5.7.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libice_1.0.4.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxrandr_1.2.3.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxfixes_4.0.3.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxinerama_1.0.3.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/libqpe/libqpe-opie_1.2.4.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libx11_1.1.5.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-proto/xproto_7.0.13.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxt_1.0.5.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxv_1.0.4.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxcursor_1.1.9.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxrender_0.9.4.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-xserver/xserver-xorg_1.5.3.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross-intermediate_4.4.2.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxext_1.0.4.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxi_1.2.0.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxmu_1.0.4.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/glibc/glibc_2.6.1.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/binutils/binutils-cross_2.20.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/glibc/glibc-initial_2.6.1.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxcomposite_0.4.0.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libsm_1.1.0.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxft_2.1.13.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/gcc/gcc-cross-initial_4.4.2.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-app/xrandr_1.2.3.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxaw_1.0.4.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxxf86vm_1.0.2.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/qte/qte-mt_2.3.10.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/xorg-lib/libxdamage_1.1.1.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/linux-libc-headers/linux-libc-headers_2.6.23.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/gnome/gconf-dbus_svn.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/avahi/avahi_0.6.24.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/libgpewidget/libgpewidget_0.117.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/libsdl/libsdl-x11_1.2.11.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/meta/external-toolchain.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/linux/linux_2.6.31.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/gtk+/gtk+_2.14.2.bb',
>>
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/libusb/libusb_0.1.12.bb',
>> '/local/Angstrom_BeagleBoard/openembedded/recipes/db/db3_3.2.9.bb']) for
>> runtime dependecy libsegfault
>> The entries resulting in this conflict were:
>> ['PREFERRED_PROVIDER_virtual/powerpc-linux-gcc = gcc-cross',
>> 'PREFERRED_PROVIDER_libxpm = libxpm', 'PREFERRED_PROVIDER_libice =
>> libice', 'PREFERRED_PROVIDER_libxrandr = libxrandr',
>> 'PREFERRED_PROVIDER_libxfixes = libxfixes',
>> 'PREFERRED_PROVIDER_libxinerama = libxinerama',
>> 'PREFERRED_PROVIDER_virtual/libqpe1 = libqpe-opie',
>> 'PREFERRED_PROVIDER_virtual/libx11 = libx11', 'PREFERRED_PROVIDER_xproto
>> = xproto', 'PREFERRED_PROVIDER_libxt = libxt', 'PREFERRED_PROVIDER_libxv
>> = libxv', 'PREFERRED_PROVIDER_libxcursor = libxcursor',
>> 'PREFERRED_PROVIDER_libxrender = libxrender',
>> 'PREFERRED_PROVIDER_virtual/xserver = xserver-xorg',
>> 'PREFERRED_PROVIDER_virtual/powerpc-linux-gcc-intermediate =
>> gcc-cross-intermediate', 'PREFERRED_PROVIDER_libxext = libxext',
>> 'PREFERRED_PROVIDER_libxi = libxi', 'PREFERRED_PROVIDER_libxmu =
>> libxmu', 'PREFERRED_PROVIDER_virtual/libc = glibc',
>> 'PREFERRED_PROVIDER_virtual/powerpc-linux-binutils = binutils-cross',
>> 'PREFERRED_PROVIDER_virtual/powerpc-linux-libc-initial = glibc-initial',
>> 'PREFERRED_PROVIDER_libxcomposite = libxcomposite',
>> 'PREFERRED_PROVIDER_libsm = libsm', 'PREFERRED_PROVIDER_libxft =
>> libxft', 'PREFERRED_PROVIDER_virtual/powerpc-linux-gcc-initial =
>> gcc-cross-initial', 'PREFERRED_PROVIDER_xrandr = xrandr',
>> 'PREFERRED_PROVIDER_libxaw = libxaw', 'PREFERRED_PROVIDER_libxxf86vm =
>> libxxf86vm', 'PREFERRED_PROVIDER_virtual/libqte2 = qte-mt',
>> 'PREFERRED_PROVIDER_libxdamage = libxdamage',
>> 'PREFERRED_PROVIDER_linux-libc-headers = linux-libc-headers',
>> 'PREFERRED_PROVIDER_gconf = gconf-dbus', 'PREFERRED_PROVIDER_avahi =
>> avahi', 'PREFERRED_PROVIDER_libgpewidget = libgpewidget',
>> 'PREFERRED_PROVIDER_virtual/libsdl = libsdl-x11',
>> 'PREFERRED_PROVIDER_virtual/libintl = external-toolchain',
>> 'PREFERRED_PROVIDER_virtual/kernel = linux', 'PREFERRED_PROVIDER_gtk+ =
>> gtk+', 'PREFERRED_PROVIDER_virtual/libusb0 = libusb',
>> 'PREFERRED_PROVIDER_virtual/db = db3']
>>
>> Why is this so hard?? I just want to use the tools I already
>> have (and my customers are comfortable with)!
>>
>
> Any ideas how I can move forward with this?

Gary,

I haven't (yet) dug into org.oe.dev much myself, but I did extend and
enhance some recipes for building Code Sourcery toolchains in Poky
originally written by the Opened Hand crew.  You won't be able to use
the "POKYMODE" system out of the box, but most of the ideas are there
(relevant PROVIDES, RPROVIDES, etc).  You might draw some inspiration
from,
http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/meta/external-csl-toolchain_2008q3-72.bb
and
http://git.pokylinux.org/cgit.cgi/poky/tree/meta/conf/distro/include/poky-external-csl2008q3.inc

Hope you find it helpful,
Mike


> --
> ------------------------------------------------------------
> 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
>

Re: Prebuilt toolchains

[Koen Kooi]

On 11-11-09 18:00, Gary Thomas wrote:
> I'd like to use my own toolchains when building OpenEmbedded.
> I've tried to follow the information at:
> http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
>
> It's a bit terse and confusing, so I'm just trying to see
> what I need (I think the section tries to discuss too many
> concepts at once)

If you're using angstrom and want to use a prebuilt CSL toolchain, you 
only need to add this to local.conf (I suspect thunderbird will linewrap 
it):

# Black magic to automatically set SDK_PATH out of PATH - don't touch this!
# Works with pretty much any external toolchain, like CS Lite or MV Pro 5
# Handles cross-toolchain vs. native toolchain
# SDK_PATH can be overwritten externally by META_SDK_PATH, e.g. for SDK
TOOLCHAIN_SYSPATH = "${@bb.data.getVar('TARGET_ARCH', d, 1) != 
bb.data.getVar('BUILD_ARCH', d, 1) and 
os.path.abspath(os.path.dirname(bb.which(bb.data.getVar('PATH', d, 1), 
bb.data.getVar('TARGET_PREFIX', d, 
1)+'cpp'))+'/../'+bb.data.getVar('TARGET_SYS', d, 1)) or ''}"
TOOLCHAIN_PATH = "${@bool(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and 
(os.path.exists(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and 
os.path.dirname(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) or 
bb.fatal('No valid toolchain in PATH')) or ''}"
SDK_PATH = "${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1), 
bb.data.getVar('META_SDK_PATH', d, 
1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}"

# Set the necessary variables to use binary CodeSourcery Lite
TARGET_VENDOR = "-none"
TARGET_CPPFLAGS_append = " -I${SDK_PATH}/${TARGET_SYS}/libc/usr/include "
TARGET_LDFLAGS_prepend = " -L${SDK_PATH}/${TARGET_SYS}/libc/lib 
-Wl,-rpath-link,${SDK_PATH}/${TARGET_SYS}/libc/lib "
TOOLCHAIN_TYPE = "external"
TOOLCHAIN_BRAND = "csl"

regards,

Koen

Re: Prebuilt toolchains

[Gary Thomas]

On 11/17/2009 12:34 AM, Koen Kooi wrote:
> On 11-11-09 18:00, Gary Thomas wrote:
>> I'd like to use my own toolchains when building OpenEmbedded.
>> I've tried to follow the information at:
>> http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
>>
>>
>> It's a bit terse and confusing, so I'm just trying to see
>> what I need (I think the section tries to discuss too many
>> concepts at once)
>
> If you're using angstrom and want to use a prebuilt CSL toolchain, you
> only need to add this to local.conf (I suspect thunderbird will linewrap
> it):
>
> # Black magic to automatically set SDK_PATH out of PATH - don't touch this!
> # Works with pretty much any external toolchain, like CS Lite or MV Pro 5
> # Handles cross-toolchain vs. native toolchain
> # SDK_PATH can be overwritten externally by META_SDK_PATH, e.g. for SDK
> TOOLCHAIN_SYSPATH = "${@bb.data.getVar('TARGET_ARCH', d, 1) !=
> bb.data.getVar('BUILD_ARCH', d, 1) and
> os.path.abspath(os.path.dirname(bb.which(bb.data.getVar('PATH', d, 1),
> bb.data.getVar('TARGET_PREFIX', d,
> 1)+'cpp'))+'/../'+bb.data.getVar('TARGET_SYS', d, 1)) or ''}"
> TOOLCHAIN_PATH = "${@bool(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and
> (os.path.exists(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and
> os.path.dirname(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) or
> bb.fatal('No valid toolchain in PATH')) or ''}"
> SDK_PATH = "${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1),
> bb.data.getVar('META_SDK_PATH', d,
> 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}"
>
> # Set the necessary variables to use binary CodeSourcery Lite
> TARGET_VENDOR = "-none"
> TARGET_CPPFLAGS_append = " -I${SDK_PATH}/${TARGET_SYS}/libc/usr/include "
> TARGET_LDFLAGS_prepend = " -L${SDK_PATH}/${TARGET_SYS}/libc/lib
> -Wl,-rpath-link,${SDK_PATH}/${TARGET_SYS}/libc/lib "
> TOOLCHAIN_TYPE = "external"
> TOOLCHAIN_BRAND = "csl"

Thanks, this looks like something to try.

I'm having a bit of trouble with the setting of 'TOOLCHAIN_SYSPATH'
(my toolchain is home-grown. not CSL).  Is there some way to debug this
line, e.g. print out the components and results?

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

Re: Prebuilt toolchains

[Gary Thomas]

On 11/18/2009 06:40 AM, Gary Thomas wrote:
> On 11/17/2009 12:34 AM, Koen Kooi wrote:
>> On 11-11-09 18:00, Gary Thomas wrote:
>>> I'd like to use my own toolchains when building OpenEmbedded.
>>> I've tried to follow the information at:
>>> http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
>>>
>>>
>>>
>>> It's a bit terse and confusing, so I'm just trying to see
>>> what I need (I think the section tries to discuss too many
>>> concepts at once)
>>
>> If you're using angstrom and want to use a prebuilt CSL toolchain, you
>> only need to add this to local.conf (I suspect thunderbird will linewrap
>> it):
>>
>> # Black magic to automatically set SDK_PATH out of PATH - don't touch
>> this!
>> # Works with pretty much any external toolchain, like CS Lite or MV Pro 5
>> # Handles cross-toolchain vs. native toolchain
>> # SDK_PATH can be overwritten externally by META_SDK_PATH, e.g. for SDK
>> TOOLCHAIN_SYSPATH = "${@bb.data.getVar('TARGET_ARCH', d, 1) !=
>> bb.data.getVar('BUILD_ARCH', d, 1) and
>> os.path.abspath(os.path.dirname(bb.which(bb.data.getVar('PATH', d, 1),
>> bb.data.getVar('TARGET_PREFIX', d,
>> 1)+'cpp'))+'/../'+bb.data.getVar('TARGET_SYS', d, 1)) or ''}"
>> TOOLCHAIN_PATH = "${@bool(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and
>> (os.path.exists(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and
>> os.path.dirname(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) or
>> bb.fatal('No valid toolchain in PATH')) or ''}"
>> SDK_PATH = "${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1),
>> bb.data.getVar('META_SDK_PATH', d,
>> 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}"
>>
>> # Set the necessary variables to use binary CodeSourcery Lite
>> TARGET_VENDOR = "-none"
>> TARGET_CPPFLAGS_append = " -I${SDK_PATH}/${TARGET_SYS}/libc/usr/include "
>> TARGET_LDFLAGS_prepend = " -L${SDK_PATH}/${TARGET_SYS}/libc/lib
>> -Wl,-rpath-link,${SDK_PATH}/${TARGET_SYS}/libc/lib "
>> TOOLCHAIN_TYPE = "external"
>> TOOLCHAIN_BRAND = "csl"
>
> Thanks, this looks like something to try.
>
> I'm having a bit of trouble with the setting of 'TOOLCHAIN_SYSPATH'
> (my toolchain is home-grown. not CSL). Is there some way to debug this
> line, e.g. print out the components and results?
>

Here's what I'm getting:
$ bitbake minimal-image
NOTE: Handling BitBake files: \ (0045/7445) [ 0 %]ERROR: No valid toolchain in PATH
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${@bool(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and (os.path.exists(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and os.path.dirname(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) or 
bb.fatal('No valid toolchain in PATH')) or ''}
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1), bb.data.getVar('META_SDK_PATH', d, 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
-isystem${STAGING_DIR_TARGET}${layout_includedir} -I${SDK_PATH}/${TARGET_SYS}/libc/usr/include
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${TARGET_CPPFLAGS} ${SELECTED_OPTIMIZATION}
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${TARGET_CFLAGS}
ERROR: Error in executing: /local/Angstrom_BeagleBoard/openembedded/recipes/xmame/xmame_0.100.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function

How can I debug what 'TOOLCHAIN_SYSPATH' is evaluating to?

Thanks


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

Re: Prebuilt toolchains

[Gary Thomas]

On 11/17/2009 12:34 AM, Koen Kooi wrote:
> On 11-11-09 18:00, Gary Thomas wrote:
>> I'd like to use my own toolchains when building OpenEmbedded.
>> I've tried to follow the information at:
>> http://docs.openembedded.org/usermanual/usermanual.html#commonuse_prebuilt_toolchain
>>
>>
>> It's a bit terse and confusing, so I'm just trying to see
>> what I need (I think the section tries to discuss too many
>> concepts at once)
>
> If you're using angstrom and want to use a prebuilt CSL toolchain, you
> only need to add this to local.conf (I suspect thunderbird will linewrap
> it):
>
> # Black magic to automatically set SDK_PATH out of PATH - don't touch this!
> # Works with pretty much any external toolchain, like CS Lite or MV Pro 5
> # Handles cross-toolchain vs. native toolchain
> # SDK_PATH can be overwritten externally by META_SDK_PATH, e.g. for SDK
> TOOLCHAIN_SYSPATH = "${@bb.data.getVar('TARGET_ARCH', d, 1) !=
> bb.data.getVar('BUILD_ARCH', d, 1) and
> os.path.abspath(os.path.dirname(bb.which(bb.data.getVar('PATH', d, 1),
> bb.data.getVar('TARGET_PREFIX', d,
> 1)+'cpp'))+'/../'+bb.data.getVar('TARGET_SYS', d, 1)) or ''}"
> TOOLCHAIN_PATH = "${@bool(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and
> (os.path.exists(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and
> os.path.dirname(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) or
> bb.fatal('No valid toolchain in PATH')) or ''}"
> SDK_PATH = "${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1),
> bb.data.getVar('META_SDK_PATH', d,
> 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}"
>
> # Set the necessary variables to use binary CodeSourcery Lite
> TARGET_VENDOR = "-none"
> TARGET_CPPFLAGS_append = " -I${SDK_PATH}/${TARGET_SYS}/libc/usr/include "
> TARGET_LDFLAGS_prepend = " -L${SDK_PATH}/${TARGET_SYS}/libc/lib
> -Wl,-rpath-link,${SDK_PATH}/${TARGET_SYS}/libc/lib "
> TOOLCHAIN_TYPE = "external"
> TOOLCHAIN_BRAND = "csl"
>

Sadly, this is not working.  I installed the latest CSL toolchain
for my platform (to be pedantic; I really want to use my extant tools).

Anyway, I now get this error:

ERROR: No valid toolchain in PATH:
  TARGET_ARCH=powerpc
  BUILD_ARCH=i686
  TARGET_PREFIX=powerpc-angstrom-linux-
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${@bool(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and (os.path.exists(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) and os.path.dirname(bb.data.getVar('TOOLCHAIN_SYSPATH', d, 1)) or 
bb.fatal('No valid toolchain in PATH:\n TARGET_ARCH=%s\n BUILD_ARCH=%s\n TARGET_PREFIX=%s' % (bb.data.getVar('TARGET_ARCH', d, 1), bb.data.getVar('BUILD_ARCH', d, 1), 
bb.data.getVar('TARGET_PREFIX', d, 1)))) or ''}
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1), bb.data.getVar('META_SDK_PATH', d, 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
-isystem${STAGING_DIR_TARGET}${layout_includedir} -I${SDK_PATH}/${TARGET_SYS}/libc/usr/include
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${TARGET_CPPFLAGS} ${SELECTED_OPTIMIZATION}
NOTE: <type 'exceptions.SystemExit'>:1 while evaluating:
${TARGET_CFLAGS}
ERROR: Error in executing: /local/Angstrom_BeagleBoard/openembedded/recipes/xmame/xmame_0.100.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function

n.b. I added the extra data in the error to try to understand
what's going on here...

Any ideas?

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