* populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH @ 2011-08-09 17:57 Richard Purdie 2011-08-10 4:00 ` Lu, Lianhao 2011-08-10 12:53 ` Kumar Gala 0 siblings, 2 replies; 12+ messages in thread From: Richard Purdie @ 2011-08-09 17:57 UTC (permalink / raw) To: openembedded-core If we don't do this, the SDK target sysroot is named generically even when it contains package architecture specific optimisations. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- diff --git a/meta/classes/populate_sdk.bbclass b/meta/classes/populate_sdk.bbclass index 0f3591b..8c19e83 100644 --- a/meta/classes/populate_sdk.bbclass +++ b/meta/classes/populate_sdk.bbclass @@ -5,7 +5,7 @@ SDK_DIR = "${WORKDIR}/sdk" SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${TMPDIR}/deploy/sdk" -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}" TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg" ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-09 17:57 populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH Richard Purdie @ 2011-08-10 4:00 ` Lu, Lianhao 2011-08-10 12:59 ` Kumar Gala 2011-08-10 12:53 ` Kumar Gala 1 sibling, 1 reply; 12+ messages in thread From: Lu, Lianhao @ 2011-08-10 4:00 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Richard Purdie wrote on 2011-08-10: > If we don't do this, the SDK target sysroot is named generically even > when it contains package architecture specific optimisations. > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- > diff --git a/meta/classes/populate_sdk.bbclass > b/meta/classes/populate_sdk.bbclass index 0f3591b..8c19e83 100644 --- > a/meta/classes/populate_sdk.bbclass +++ > b/meta/classes/populate_sdk.bbclass @@ -5,7 +5,7 @@ SDK_DIR = > "${WORKDIR}/sdk" > SDK_OUTPUT = "${SDK_DIR}/image" > SDK_DEPLOY = "${TMPDIR}/deploy/sdk" > -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" > +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" In gcc-configure-sdk.inc, it is set "--with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS}". Is there any inconsistency? Best Regards, Lianhao > TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk > task-cross-canadian-${TRANSLATED_TARGET_ARCH}" TOOLCHAIN_TARGET_TASK ?= > "task-core-standalone-sdk-target > task-core-standalone-sdk-target-dbg" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 4:00 ` Lu, Lianhao @ 2011-08-10 12:59 ` Kumar Gala 2011-08-10 13:07 ` Richard Purdie 0 siblings, 1 reply; 12+ messages in thread From: Kumar Gala @ 2011-08-10 12:59 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Aug 9, 2011, at 11:00 PM, Lu, Lianhao wrote: > Richard Purdie wrote on 2011-08-10: >> If we don't do this, the SDK target sysroot is named generically even >> when it contains package architecture specific optimisations. >> >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- >> diff --git a/meta/classes/populate_sdk.bbclass >> b/meta/classes/populate_sdk.bbclass index 0f3591b..8c19e83 100644 --- >> a/meta/classes/populate_sdk.bbclass +++ >> b/meta/classes/populate_sdk.bbclass @@ -5,7 +5,7 @@ SDK_DIR = >> "${WORKDIR}/sdk" >> SDK_OUTPUT = "${SDK_DIR}/image" >> SDK_DEPLOY = "${TMPDIR}/deploy/sdk" >> -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" >> +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" > > In gcc-configure-sdk.inc, it is set "--with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS}". > Is there any inconsistency? Binutils might also need updating. - k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 12:59 ` Kumar Gala @ 2011-08-10 13:07 ` Richard Purdie 2011-08-10 13:23 ` Richard Purdie 0 siblings, 1 reply; 12+ messages in thread From: Richard Purdie @ 2011-08-10 13:07 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, 2011-08-10 at 07:59 -0500, Kumar Gala wrote: > On Aug 9, 2011, at 11:00 PM, Lu, Lianhao wrote: > > > Richard Purdie wrote on 2011-08-10: > >> If we don't do this, the SDK target sysroot is named generically even > >> when it contains package architecture specific optimisations. > >> > >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- > >> diff --git a/meta/classes/populate_sdk.bbclass > >> b/meta/classes/populate_sdk.bbclass index 0f3591b..8c19e83 100644 --- > >> a/meta/classes/populate_sdk.bbclass +++ > >> b/meta/classes/populate_sdk.bbclass @@ -5,7 +5,7 @@ SDK_DIR = > >> "${WORKDIR}/sdk" > >> SDK_OUTPUT = "${SDK_DIR}/image" > >> SDK_DEPLOY = "${TMPDIR}/deploy/sdk" > >> -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" > >> +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" > > > > In gcc-configure-sdk.inc, it is set "--with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS}". > > Is there any inconsistency? > > Binutils might also need updating. This is an interesting question. We certainly compile in a default path for the sysroot but we in general always override it from the environment anyway. As long as the package architectures for the sdk components are correct we should be able to update the defaults. I've not yet checked that though. Cheers, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 13:07 ` Richard Purdie @ 2011-08-10 13:23 ` Richard Purdie 2011-08-10 13:34 ` Gary Thomas 0 siblings, 1 reply; 12+ messages in thread From: Richard Purdie @ 2011-08-10 13:23 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, 2011-08-10 at 14:07 +0100, Richard Purdie wrote: > On Wed, 2011-08-10 at 07:59 -0500, Kumar Gala wrote: > > On Aug 9, 2011, at 11:00 PM, Lu, Lianhao wrote: > > > > > Richard Purdie wrote on 2011-08-10: > > >> If we don't do this, the SDK target sysroot is named generically even > > >> when it contains package architecture specific optimisations. > > >> > > >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- > > >> diff --git a/meta/classes/populate_sdk.bbclass > > >> b/meta/classes/populate_sdk.bbclass index 0f3591b..8c19e83 100644 --- > > >> a/meta/classes/populate_sdk.bbclass +++ > > >> b/meta/classes/populate_sdk.bbclass @@ -5,7 +5,7 @@ SDK_DIR = > > >> "${WORKDIR}/sdk" > > >> SDK_OUTPUT = "${SDK_DIR}/image" > > >> SDK_DEPLOY = "${TMPDIR}/deploy/sdk" > > >> -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" > > >> +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" > > > > > > In gcc-configure-sdk.inc, it is set "--with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS}". > > > Is there any inconsistency? > > > > Binutils might also need updating. > > This is an interesting question. We certainly compile in a default path > for the sysroot but we in general always override it from the > environment anyway. > > As long as the package architectures for the sdk components are correct > we should be able to update the defaults. I've not yet checked that > though. This is something which gets built into gcc-cross-canadian-${TARGET_ARCH} (i.e i586/armpowerpc). Since we use the target libs (inc libgcc) and everything in that package is multiple platform enabled, I think the current behaviour is correct. It might point an an invalid default sysroot but its up to the package architecture specific environment files to correct that. This means the one toolchain can be shared over multiple package architectures. I'm open to other views of that but I think what we have there is correct and should work with the above change. Cheers, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 13:23 ` Richard Purdie @ 2011-08-10 13:34 ` Gary Thomas 2011-08-10 13:40 ` Richard Purdie 0 siblings, 1 reply; 12+ messages in thread From: Gary Thomas @ 2011-08-10 13:34 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 2011-08-10 07:23, Richard Purdie wrote: > On Wed, 2011-08-10 at 14:07 +0100, Richard Purdie wrote: >> On Wed, 2011-08-10 at 07:59 -0500, Kumar Gala wrote: >>> On Aug 9, 2011, at 11:00 PM, Lu, Lianhao wrote: >>> >>>> Richard Purdie wrote on 2011-08-10: >>>>> If we don't do this, the SDK target sysroot is named generically even >>>>> when it contains package architecture specific optimisations. >>>>> >>>>> Signed-off-by: Richard Purdie<richard.purdie@linuxfoundation.org> --- >>>>> diff --git a/meta/classes/populate_sdk.bbclass >>>>> b/meta/classes/populate_sdk.bbclass index 0f3591b..8c19e83 100644 --- >>>>> a/meta/classes/populate_sdk.bbclass +++ >>>>> b/meta/classes/populate_sdk.bbclass @@ -5,7 +5,7 @@ SDK_DIR = >>>>> "${WORKDIR}/sdk" >>>>> SDK_OUTPUT = "${SDK_DIR}/image" >>>>> SDK_DEPLOY = "${TMPDIR}/deploy/sdk" >>>>> -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" >>>>> +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" >>>> >>>> In gcc-configure-sdk.inc, it is set "--with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS}". >>>> Is there any inconsistency? >>> >>> Binutils might also need updating. >> >> This is an interesting question. We certainly compile in a default path >> for the sysroot but we in general always override it from the >> environment anyway. >> >> As long as the package architectures for the sdk components are correct >> we should be able to update the defaults. I've not yet checked that >> though. > > This is something which gets built into > gcc-cross-canadian-${TARGET_ARCH} (i.e i586/armpowerpc). Since we use > the target libs (inc libgcc) and everything in that package is multiple > platform enabled, I think the current behaviour is correct. It might > point an an invalid default sysroot but its up to the package > architecture specific environment files to correct that. This means the > one toolchain can be shared over multiple package architectures. > > I'm open to other views of that but I think what we have there is > correct and should work with the above change. On a related thought to these changes - how does this play if you use multiple SDKs for different, but somewhat related, architectures? I'd like to create a simple SDK (just toolchain mostly) using 'meta-toolchain' for both armv5te and armv7a and install them simultaneously on the same host. My previous attempts at this fell flat as there were a number of files marked as "arm" (i.e. not armv5te or arvm7a) that were common between the two SDK packages, but they didn't seem to be identical. With these changes, will it be possible to support such sets of multiple toolchains? (No, ADT is not the answer - I just want the toolchains) Thanks (sorry if this seems I hijacked your thread - my question is related to what you are discussing here) -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 13:34 ` Gary Thomas @ 2011-08-10 13:40 ` Richard Purdie 2011-08-10 13:48 ` Gary Thomas 0 siblings, 1 reply; 12+ messages in thread From: Richard Purdie @ 2011-08-10 13:40 UTC (permalink / raw) To: Gary Thomas; +Cc: Patches and discussions about the oe-core layer On Wed, 2011-08-10 at 07:34 -0600, Gary Thomas wrote: > On a related thought to these changes - how does this play if > you use multiple SDKs for different, but somewhat related, architectures? > I'd like to create a simple SDK (just toolchain mostly) using 'meta-toolchain' > for both armv5te and armv7a and install them simultaneously on the same > host. My previous attempts at this fell flat as there were a number of > files marked as "arm" (i.e. not armv5te or arvm7a) that were common between > the two SDK packages, but they didn't seem to be identical. This is supposed to work but wouldn't due to the issue and the patch I've proposed. Whether that is the only issue I don't know. Can you remember which files we're talking about here? > With these changes, will it be possible to support such sets of multiple > toolchains? (No, ADT is not the answer - I just want the toolchains) ADT uses meta-toolchain-* so its all related. Cheers, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 13:40 ` Richard Purdie @ 2011-08-10 13:48 ` Gary Thomas 2011-08-10 14:23 ` Kumar Gala 2011-08-17 15:44 ` Gary Thomas 0 siblings, 2 replies; 12+ messages in thread From: Gary Thomas @ 2011-08-10 13:48 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On 2011-08-10 07:40, Richard Purdie wrote: > On Wed, 2011-08-10 at 07:34 -0600, Gary Thomas wrote: >> On a related thought to these changes - how does this play if >> you use multiple SDKs for different, but somewhat related, architectures? >> I'd like to create a simple SDK (just toolchain mostly) using 'meta-toolchain' >> for both armv5te and armv7a and install them simultaneously on the same >> host. My previous attempts at this fell flat as there were a number of >> files marked as "arm" (i.e. not armv5te or arvm7a) that were common between >> the two SDK packages, but they didn't seem to be identical. > > This is supposed to work but wouldn't due to the issue and the patch > I've proposed. Whether that is the only issue I don't know. I'll be glad to test this once you've worked it out. > > Can you remember which files we're talking about here? Not right off - there were just a ton of directories with only arm in the path that seemed to be architecture dependent. I think it's all related to TARGET_SYS vs MULTIMACH_TARGET_SYS and how/where they are used. > >> With these changes, will it be possible to support such sets of multiple >> toolchains? (No, ADT is not the answer - I just want the toolchains) > > ADT uses meta-toolchain-* so its all related. Fair enough, I just don't want to have to use ADT just to install a toolchain. Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 13:48 ` Gary Thomas @ 2011-08-10 14:23 ` Kumar Gala 2011-08-17 15:44 ` Gary Thomas 1 sibling, 0 replies; 12+ messages in thread From: Kumar Gala @ 2011-08-10 14:23 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Aug 10, 2011, at 8:48 AM, Gary Thomas wrote: > On 2011-08-10 07:40, Richard Purdie wrote: >> On Wed, 2011-08-10 at 07:34 -0600, Gary Thomas wrote: >>> On a related thought to these changes - how does this play if >>> you use multiple SDKs for different, but somewhat related, architectures? >>> I'd like to create a simple SDK (just toolchain mostly) using 'meta-toolchain' >>> for both armv5te and armv7a and install them simultaneously on the same >>> host. My previous attempts at this fell flat as there were a number of >>> files marked as "arm" (i.e. not armv5te or arvm7a) that were common between >>> the two SDK packages, but they didn't seem to be identical. >> >> This is supposed to work but wouldn't due to the issue and the patch >> I've proposed. Whether that is the only issue I don't know. > > I'll be glad to test this once you've worked it out. > >> >> Can you remember which files we're talking about here? > > Not right off - there were just a ton of directories with only arm in the > path that seemed to be architecture dependent. I think it's all related to > TARGET_SYS vs MULTIMACH_TARGET_SYS and how/where they are used. > >> >>> With these changes, will it be possible to support such sets of multiple >>> toolchains? (No, ADT is not the answer - I just want the toolchains) >> >> ADT uses meta-toolchain-* so its all related. > > Fair enough, I just don't want to have to use ADT just to install a toolchain. And this is also something we're wanting to work to allow different PPC toolchain variants to live together - k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-10 13:48 ` Gary Thomas 2011-08-10 14:23 ` Kumar Gala @ 2011-08-17 15:44 ` Gary Thomas 2011-09-05 19:45 ` Richard Purdie 1 sibling, 1 reply; 12+ messages in thread From: Gary Thomas @ 2011-08-17 15:44 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On 2011-08-10 07:48, Gary Thomas wrote: > On 2011-08-10 07:40, Richard Purdie wrote: >> On Wed, 2011-08-10 at 07:34 -0600, Gary Thomas wrote: >>> On a related thought to these changes - how does this play if >>> you use multiple SDKs for different, but somewhat related, architectures? >>> I'd like to create a simple SDK (just toolchain mostly) using 'meta-toolchain' >>> for both armv5te and armv7a and install them simultaneously on the same >>> host. My previous attempts at this fell flat as there were a number of >>> files marked as "arm" (i.e. not armv5te or arvm7a) that were common between >>> the two SDK packages, but they didn't seem to be identical. >> >> This is supposed to work but wouldn't due to the issue and the patch >> I've proposed. Whether that is the only issue I don't know. > > I'll be glad to test this once you've worked it out. > Any progress on this yet? The discussion seems to have died down... -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-17 15:44 ` Gary Thomas @ 2011-09-05 19:45 ` Richard Purdie 0 siblings, 0 replies; 12+ messages in thread From: Richard Purdie @ 2011-09-05 19:45 UTC (permalink / raw) To: Gary Thomas; +Cc: Patches and discussions about the oe-core layer On Wed, 2011-08-17 at 09:44 -0600, Gary Thomas wrote: > On 2011-08-10 07:48, Gary Thomas wrote: > > On 2011-08-10 07:40, Richard Purdie wrote: > >> On Wed, 2011-08-10 at 07:34 -0600, Gary Thomas wrote: > >>> On a related thought to these changes - how does this play if > >>> you use multiple SDKs for different, but somewhat related, architectures? > >>> I'd like to create a simple SDK (just toolchain mostly) using 'meta-toolchain' > >>> for both armv5te and armv7a and install them simultaneously on the same > >>> host. My previous attempts at this fell flat as there were a number of > >>> files marked as "arm" (i.e. not armv5te or arvm7a) that were common between > >>> the two SDK packages, but they didn't seem to be identical. > >> > >> This is supposed to work but wouldn't due to the issue and the patch > >> I've proposed. Whether that is the only issue I don't know. > > > > I'll be glad to test this once you've worked it out. > > Any progress on this yet? The discussion seems to have died down... I merged the patch in question so I'm open to feedback on whether this works better now... Cheers, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH 2011-08-09 17:57 populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH Richard Purdie 2011-08-10 4:00 ` Lu, Lianhao @ 2011-08-10 12:53 ` Kumar Gala 1 sibling, 0 replies; 12+ messages in thread From: Kumar Gala @ 2011-08-10 12:53 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Aug 9, 2011, at 12:57 PM, Richard Purdie wrote: > If we don't do this, the SDK target sysroot is named generically even > when it contains package architecture specific optimisations. > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > diff --git a/meta/classes/populate_sdk.bbclass b/meta/classes/populate_sdk.bbclass > index 0f3591b..8c19e83 100644 > --- a/meta/classes/populate_sdk.bbclass > +++ b/meta/classes/populate_sdk.bbclass > @@ -5,7 +5,7 @@ SDK_DIR = "${WORKDIR}/sdk" > SDK_OUTPUT = "${SDK_DIR}/image" > SDK_DEPLOY = "${TMPDIR}/deploy/sdk" > > -SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" > +SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}" > > TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}" > TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg" > Ack. - k ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-09-05 19:50 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-08-09 17:57 populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH Richard Purdie 2011-08-10 4:00 ` Lu, Lianhao 2011-08-10 12:59 ` Kumar Gala 2011-08-10 13:07 ` Richard Purdie 2011-08-10 13:23 ` Richard Purdie 2011-08-10 13:34 ` Gary Thomas 2011-08-10 13:40 ` Richard Purdie 2011-08-10 13:48 ` Gary Thomas 2011-08-10 14:23 ` Kumar Gala 2011-08-17 15:44 ` Gary Thomas 2011-09-05 19:45 ` Richard Purdie 2011-08-10 12:53 ` Kumar Gala
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox