Re: populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH

[Gary Thomas <gary@mlbassoc.com>]

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