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

PATCH Richard Purdie 4 participants 12 messages Aug 9, 2011 – Sep 5, 2011

Share & tools

Richard Purdie

author

2011-08-09 18:02 UTC #0 lore raw

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 <[email protected]>

---

meta/classes/populate_sdk.bbclass +1 -1

index 0f3591b..8c19e83 100644
@@ -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"

Lu, Lianhao

2011-08-10 04:05 UTC #1 lore raw

Richard Purdie wrote on 2011-08-10:

meta/classes/populate_sdk.bbclass SDK_DIR = "${WORKDIR}/sdk" · line 8

Quoted 13 lines

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 <[email protected]> ---
(quoted diff) +0 -0
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"
meta/classes/populate_sdk.bbclass +1 -1
-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

Quoted 4 lines

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"

Kumar Gala

2011-08-10 13:04 UTC #2 lore raw

Quoted 4 lines · Lianhao

Richard Purdie wrote on 2011-08-10:
Quoted 3 lines
If we don't do this, the SDK target sysroot is named generically even when it contains package architecture specific optimisations.

Quoted 13 lines

meta/classes/populate_sdk.bbclass SDK_DIR = "${WORKDIR}/sdk" · line 8
Quoted 10 lines
Signed-off-by Richard Purdie <[email protected]> ---
(quoted diff) +0 -0
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"
meta/classes/populate_sdk.bbclass +1 -1
-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

Richard Purdie

author

2011-08-10 13:13 UTC #3 lore raw

Quoted 20 lines · Kumar Gala

Quoted 4 lines · Lianhao
Richard Purdie wrote on 2011-08-10:
Quoted 3 lines
If we don't do this, the SDK target sysroot is named generically even when it contains package architecture specific optimisations.
Quoted 13 lines
meta/classes/populate_sdk.bbclass SDK_DIR = "${WORKDIR}/sdk" · line 8
Quoted 10 lines
Signed-off-by Richard Purdie <[email protected]> ---
(quoted diff) +0 -0
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"
meta/classes/populate_sdk.bbclass +1 -1
-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?

Quoted 1 line

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

Richard Purdie

author

2011-08-10 13:29 UTC #4 lore raw

Quoted 23 lines · Richard Purdie

Quoted 20 lines · Kumar Gala
Quoted 4 lines · Lianhao
Richard Purdie wrote on 2011-08-10:
Quoted 3 lines
If we don't do this, the SDK target sysroot is named generically even when it contains package architecture specific optimisations.
Quoted 13 lines
meta/classes/populate_sdk.bbclass SDK_DIR = "${WORKDIR}/sdk" · line 8
Quoted 10 lines
Signed-off-by Richard Purdie <[email protected]> ---
(quoted diff) +0 -0
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"
meta/classes/populate_sdk.bbclass +1 -1
-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?
Quoted 1 line
Binutils might also need updating.

Quoted 7 lines

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

Gary Thomas

2011-08-10 13:39 UTC #5 lore raw

Quoted 40 lines · Richard Purdie

Quoted 23 lines · Richard Purdie
Quoted 20 lines · Kumar Gala
Quoted 4 lines · Lianhao
Richard Purdie wrote on 2011-08-10:
Quoted 3 lines
If we don't do this, the SDK target sysroot is named generically even when it contains package architecture specific optimisations.
Quoted 13 lines
meta/classes/populate_sdk.bbclass SDK_DIR = "${WORKDIR}/sdk" · line 8
Quoted 10 lines
Signed-off-by Richard Purdie<[email protected]> ---
(quoted diff) +0 -0
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"
meta/classes/populate_sdk.bbclass +1 -1
-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?
Quoted 1 line
Binutils might also need updating.
Quoted 7 lines
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.

Quoted 2 lines

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)

Signature · 4 lines

------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Richard Purdie

author

2011-08-10 13:45 UTC #6 lore raw

Quoted 7 lines · Gary Thomas

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?

Quoted 2 lines

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

Gary Thomas

2011-08-10 13:52 UTC #7 lore raw

Quoted 11 lines · Richard Purdie

Quoted 7 lines · Gary Thomas
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.

Quoted 2 lines

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.

Quoted 5 lines

Quoted 3 lines
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

Signature · 4 lines

------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Kumar Gala

2011-08-10 14:28 UTC #8 lore raw

Quoted 23 lines · Gary Thomas

Quoted 11 lines · Richard Purdie
Quoted 7 lines · Gary Thomas
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.
Quoted 2 lines
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.
Quoted 1 line

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Gary Thomas

2011-08-17 15:49 UTC #9 lore raw

In reply to Gary Thomas

Quoted 10 lines · Gary Thomas

Quoted 9 lines · Richard Purdie
Quoted 7 lines · Gary Thomas
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.

Quoted 5 lines

Quoted 2 lines
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...

Signature · 4 lines

------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Richard Purdie

author Applied

2011-09-05 19:50 UTC #10 lore raw

Quoted 11 lines · Gary Thomas

Quoted 10 lines · Gary Thomas
Quoted 9 lines · Richard Purdie
Quoted 7 lines · Gary Thomas
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.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Kumar Gala

2011-08-10 12:57 UTC #11 lore raw

In reply to Richard Purdie

Quoted 16 lines · Richard Purdie

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 <[email protected]>
---
meta/classes/populate_sdk.bbclass +0 -0
index 0f3591b..8c19e83 100644
@@ -5,7 +5,7 @@ SDK_DIR = "${WORKDIR}/sdk"
SDK_OUTPUT = "${SDK_DIR}/image"
SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
meta/classes/populate_sdk.bbclass +1 -1
-SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}"
+SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}"

Quoted 3 lines

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