[OE-core] SDK and external toolchain

[Mark Hatle]

On 7/26/12 2:14 AM, Matthieu CRAPET wrote:
> Greetings,
>
> Updated recently my oe-core and faced an unwanted side effect.
> You need to know that I'm using an externel (linaro) toolchain (my
> .bb/.inc are a clone of "sourcery" toolchain example).
> My toolchain is compiled against a custom (external) eglibc 2.15.
>
> Since commit a0de2a56f19ae4d8cd88e46e96917a7a019fe1ab --
> image.bbclass: Add support to build the SDK in parallel with the image
> http://cgit.openembedded.org/openembedded-core/commit/?id=a0de2a56f19ae4
> d8cd88e46e96917a7a019fe1ab

I have run into similar failures.  Your are missing some items in the PROVIDES 
most likely, and as for the multiple providers the PREFERRED_PROVIDER is the 
right answer.

We list a preferred provider for:

linux-libc-headers, linux-libc-headers-dev, virtual/${TARGET_PREFIX}gcc, 
virtual/${TARGET_PREFIX}gcc-initial, virtual/${TARGET_PREFIX}gcc-intermediate, 
virtual/${TARGET_PREFIX}g++, virtual/${TARGET_PREFIX}binutils, 
virtual/${TARGET_PREFIX}libc-for-gcc, virtual/${TARGET_PREFIX}compilerlibs, 
libgcc, virtual/libc, virtual/libintl, virtual/libiconv, glibc-thread-db, 
virtual/linux-libc-headers, eglibc, binutils-cross, gcc-cross

(We have some more, but they are only useful when building an SDK with a custom 
import script...)

> my images generation are failing because it tries to compile eglib 2.16
> and do_configure fails. I have also 3 errors:
> ERROR: Multiple .bb files are due to be built which each provide
> virtual/libc (.../meta/recipes-core/eglibc/eglibc_2.15.bb
> .../meta-ingenico/recipes/external-linaro-toolchain/external-linaro-tool
> chain.bb).

virtual/libc is the item for the above

>   This usually means one provides something the other doesn't and should.
> ERROR: Multiple .bb files are due to be built which each provide
> virtual/arm-ingenico-linux-gnueabi-libc-for-gcc
> (.../meta/recipes-core/eglibc/eglibc_2.15.bb
> .../meta-ingenico/recipes/external-linaro-toolchain/external-linaro-tool
> chain.bb).

virtual/${TARGET_PREFIX}libc-for-gcc is the item for the above

>   This usually means one provides something the other doesn't and should.
> ERROR: Multiple .bb files are due to be built which each provide
> virtual/libiconv (.../meta/recipes-core/eglibc/eglibc_2.15.bb
> .../meta-ingenico/recipes/external-linaro-toolchain/external-linaro-tool
> chain.bb).
>   This usually means one provides something the other doesn't and should.

and virtual/libiconv is the item for the above...

> Notice that "PREFERRED_PROVIDER"s are correctly defined (like in
> distro/include/tcmode-external-sourcery.inc). And I use bitbake 1.15.3.

We had to add additional preferred_providers to the tcmode-external-sourcey.inc. 
  We (similar to you) have a custom binary toolchain... so the tailoring was 
required to get our stuff to work right.

> For now I fixed it crudely, because I don't need SDK.
>
> diff --git a/meta/classes/toolchain-scripts.bbclass
> b/meta/classes/toolchain-scripts.bbclass
> index 44284c3..f5fd4d7 100644
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -136,7 +136,7 @@ toolchain_create_sdk_env_script_for_installer () {
>   #we get the cached site config in the runtime
>   TOOLCHAIN_CONFIGSITE_NOCACHE = "${@siteinfo_get_files(d, True)}"
>   TOOLCHAIN_CONFIGSITE_SYSROOTCACHE =
> "${STAGING_DATADIR}/${TARGET_SYS}_config_site.d"
> -TOOLCHAIN_NEED_CONFIGSITE_CACHE = "${TCLIBC} ncurses"
> +TOOLCHAIN_NEED_CONFIGSITE_CACHE = "ncurses"

That is incorrect.. the CONFIGSITE_CACHE should be generated for the TCLIBC.  If 
you don't do that, then you will be running the same configure steps -- looking 
for basic glibc information over and over and over, causing a fairly expensive 
performance penalty.

>
>   #This function create a site config file
>   toolchain_create_sdk_siteconfig () {
> ---
>
> populate_sdk_base.bbclass inheric toolchain-scripts which adds the
> (unwanted) eglibc dependency.

It's not an "eglibc" dependency, it's a libc dependency.  You definitely want 
that!  Otherwise you can end up with an SDK w/o a libc...

> Maybe this should be conditional from TOOLCHAIN_TARGET_TASK value?  Or
> dependencies should be added only when calling
> task-core-standalone-sdk-target?
> In my use case, when I bitbake an image recipe, I don't want to deal
> with SDK.

I don't know the exact bitbake version numbers, but a fairly recent bitbake 
change (approx the same time as the patch you referred to) resolves an issue 
where un-used tasks were adding in build dependencies and causing the system to 
take longer to execute.)  So as long as you have a recent bitbake to match the 
recent oe-core, you should be ok.

> Concerning errors, is there a way to see what's not provided in order to
> fix virtual/libc message (bitbake -e) ?

bitbake -e, grep for PREFERRED_PROVIDER to see what you -do- have listed.. 
Otherwise no, you just have to go off of the error messages and add things until 
you've listed everything.

General rule of thumb, anything thats listed in the PROVIDES of the recipe will 
be needed in the PREFERRED_PROVIDER as well.

--Mark

> Best regards,
> Matthieu
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>