Re: Prebuilt toolchains

[Gary Thomas <gary@mlbassoc.com>]

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