Re: [OE-core] SDK and external toolchain
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 ;(
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] SDK and external toolchain
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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
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=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_PROVIDERs 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
Re: [OE-core] SDK and external toolchain
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.ha...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
