SDK and external toolchain

SDK and external toolchain

[Matthieu CRAPET]

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

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

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

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"

 #This function create a site config file
 toolchain_create_sdk_siteconfig () {
---

populate_sdk_base.bbclass inheric toolchain-scripts which adds the
(unwanted) eglibc dependency.
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.

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

Best regards,
Matthieu

Re: 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: SDK and external toolchain

[Chris Larson]

On Thu, Jul 26, 2012 at 9:37 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> 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.

No, he's right, this is a bug in toolchain-scripts.bbclass. We could
work around it in the recipe via RPROVIDES_${PN}, but
TOOLCHAIN_NEED_CONFIGSITE_CACHE feeds directly into task 'depends', so
it's pulling in ${TCLIBC} explicitly rather than the more accurate
'virtual/libc'.
-- 
Christopher Larson

Re: SDK and external toolchain

[Mark Hatle]

On 7/26/12 1:14 PM, Chris Larson wrote:
> On Thu, Jul 26, 2012 at 9:37 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> 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.
>
> No, he's right, this is a bug in toolchain-scripts.bbclass. We could
> work around it in the recipe via RPROVIDES_${PN}, but
> TOOLCHAIN_NEED_CONFIGSITE_CACHE feeds directly into task 'depends', so
> it's pulling in ${TCLIBC} explicitly rather than the more accurate
> 'virtual/libc'.
>

The config site file though isn't called "virtual/libc".  My understanding what 
that all that variable did was set the list of config site files, but didn't 
directly affect the dependency mapping.  If it does, then there is a definite 
issue w/ dependency vs file mappings.

--Mark

Re: SDK and external toolchain

[Richard Purdie]

On Thu, 2012-07-26 at 13:32 -0500, Mark Hatle wrote:
> On 7/26/12 1:14 PM, Chris Larson wrote:
> > On Thu, Jul 26, 2012 at 9:37 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> >>> 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.
> >
> > No, he's right, this is a bug in toolchain-scripts.bbclass. We could
> > work around it in the recipe via RPROVIDES_${PN}, but
> > TOOLCHAIN_NEED_CONFIGSITE_CACHE feeds directly into task 'depends', so
> > it's pulling in ${TCLIBC} explicitly rather than the more accurate
> > 'virtual/libc'.
> >
> 
> The config site file though isn't called "virtual/libc".  My understanding what 
> that all that variable did was set the list of config site files, but didn't 
> directly affect the dependency mapping.  If it does, then there is a definite 
> issue w/ dependency vs file mappings.

The trouble as I understand it is we need to know both the dependency
name and the config/site cache name.

We'll probably have to change siteconfig.bbclass to generate libc_config
instead of ${PN}_config (create an intermediate variable the libc
recipes override).

We can then specify something like virtual/libc:libc in
TOOLCHAIN_NEED_CONFIGSITE_CACHE. Of course that probably still won't
work if you actually try and build meta-toolchain, we might just have to
skip things that don't exist...

Cheers,

Richard 

Re: SDK and external toolchain

[Marcin Juszkiewicz]

W dniu 26.07.2012 21:58, Richard Purdie pisze:
> On Thu, 2012-07-26 at 13:32 -0500, Mark Hatle wrote:
>> On 7/26/12 1:14 PM, Chris Larson wrote:
>>> On Thu, Jul 26, 2012 at 9:37 AM, Mark Hatle <mark.hatle at windriver.com> wrote:
>>>>> 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.
>>>
>>> No, he's right, this is a bug in toolchain-scripts.bbclass. We could
>>> work around it in the recipe via RPROVIDES_${PN}, but
>>> TOOLCHAIN_NEED_CONFIGSITE_CACHE feeds directly into task 'depends', so
>>> it's pulling in ${TCLIBC} explicitly rather than the more accurate
>>> 'virtual/libc'.
>>>
>>
>> The config site file though isn't called "virtual/libc".  My understanding what 
>> that all that variable did was set the list of config site files, but didn't 
>> directly affect the dependency mapping.  If it does, then there is a definite 
>> issue w/ dependency vs file mappings.
> 
> The trouble as I understand it is we need to know both the dependency
> name and the config/site cache name.
> 
> We'll probably have to change siteconfig.bbclass to generate libc_config
> instead of ${PN}_config (create an intermediate variable the libc
> recipes override).
> 
> We can then specify something like virtual/libc:libc in
> TOOLCHAIN_NEED_CONFIGSITE_CACHE. Of course that probably still won't
> work if you actually try and build meta-toolchain, we might just have to
> skip things that don't exist...

Issue is still present ;(

Re: SDK and external toolchain

[Marcin Juszkiewicz]

I did not tested it without external toolchain yet and have
no idea is it good way at all. 

diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass
index 050e799..f5801a8 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -142,7 +142,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"
 
 #This function create a site config file
 toolchain_create_sdk_siteconfig () {
@@ -161,6 +161,11 @@ toolchain_create_sdk_siteconfig () {
                        cat ${TOOLCHAIN_CONFIGSITE_SYSROOTCACHE}/${sitefile}_config >> $siteconfig
                fi
        done
+       if [ "${TCMODE}" = "default" ]; then
+               if [ -r ${TOOLCHAIN_CONFIGSITE_SYSROOTCACHE}/${TCLIBC}_config ]; then
+                       cat ${TOOLCHAIN_CONFIGSITE_SYSROOTCACHE}/${TCLIBC}_config >> $siteconfig
+               fi
+       fi
 }
 # The immediate expansion above can result in unwanted path dependencies here
 toolchain_create_sdk_siteconfig[vardepsexclude] = "TOOLCHAIN_CONFIGSITE_SYSROOTCACHE"

Re: SDK and external toolchain

[Matthieu CRAPET]

Hi,

@Mark

Still have the 3 errors. I added to my tcmode include file (without success):

PREFERRED_PROVIDER_eglibc = "external-linaro-toolchain"
PREFERRED_PROVIDER_binutils-cross = "external-linaro-toolchain"
PREFERRED_PROVIDER_gcc-cross = "external-linaro-toolchain"
# eglibc-locale
PREFERRED_PROVIDER_virtual/libc-locale = "external-linaro-toolchain"
# eglibc-nativesdk
PREFERRED_PROVIDER_virtual/libc-nativesdk = "external-linaro-toolchain"
PREFERRED_PROVIDER_virtual/libiconv-nativesdk =  "external-linaro-toolchain"

This is not so important now, as I patched toolchain-scripts.bbclass.

@Christopher

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026659.html
Tried it, this is just fine here!

Thanks for your support guys.

Best regards,
Matthieu


-----Message d'origine-----
De : openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] De la part de Mark Hatle
Envoyé : jeudi 26 juillet 2012 18:37
À : openembedded-core@lists.openembedded.org
Objet : Re: [OE-core] SDK and external toolchain

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=a0de2a56f19a
> e4
> 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-to
> ol
> 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-to
> ol
> 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-to
> ol
> 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>


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