[PATCH 1/1] poky.conf: move the SDK install into version directories

[PATCH 1/1] poky.conf: move the SDK install into version directories

[Joshua Lock]

It's desirable to be able to have SDK toolchains installed from multiple
versions of Poky, enable this by installing the toolchains into a subdirectory
of /opt/poky/ based on the distro version.

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 meta/conf/distro/poky.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/poky.conf b/meta/conf/distro/poky.conf
index b3c9f1a..ca73e64 100644
--- a/meta/conf/distro/poky.conf
+++ b/meta/conf/distro/poky.conf
@@ -60,7 +60,7 @@ POKYLIBC ?= "eglibc"
 require conf/distro/include/poky-${POKYLIBC}.inc
 
 SDK_NAME = "${DISTRO}-${POKYLIBC}-${SDK_ARCH}-${TARGET_ARCH}"
-SDKPATH = "/opt/${DISTRO}"
+SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
 
 CACHE = "${TMPDIR}/cache/${POKYMODE}-${POKYLIBC}${@['', '/' + str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d, 1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}"
 
-- 
1.7.3.2

[PATCH 0/1] Enable parallel installations of SDK's from different Poky versions

[Joshua Lock]

Simple patch to enable multiple SDK installations under the /opt/poky namespace separated into folders matching the version of the corresponding Poky distro release.

Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: josh/sdk
  Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=josh/sdk

Thanks,
    Joshua Lock <josh@linux.intel.com>
---


Joshua Lock (1):
  poky.conf: move the SDK install into version directories

 meta/conf/distro/poky.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
1.7.3.2

Re: [PATCH 1/1] poky.conf: move the SDK install into versiondirectories

[Mark Hatle]

As we move beyond 1.0 work.  Would it make sense to focus on making sure the SDK
tooling works no matter where it is installed?

The compiler/linker can already do this... the other components that may be part
of the SDK may need some slight changes to detect their current run-time
location and adjust internal paths as necessary.

(We have experience doing this for Wind River Linux, so we should be able to
help out if it's a desired feature for Poky.)

--Mark

On 11/19/10 5:59 AM, Joshua Lock wrote:
> It's desirable to be able to have SDK toolchains installed from multiple
> versions of Poky, enable this by installing the toolchains into a subdirectory
> of /opt/poky/ based on the distro version.
> 
> Signed-off-by: Joshua Lock <josh@linux.intel.com>
> ---
>  meta/conf/distro/poky.conf |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/conf/distro/poky.conf b/meta/conf/distro/poky.conf
> index b3c9f1a..ca73e64 100644
> --- a/meta/conf/distro/poky.conf
> +++ b/meta/conf/distro/poky.conf
> @@ -60,7 +60,7 @@ POKYLIBC ?= "eglibc"
>  require conf/distro/include/poky-${POKYLIBC}.inc
>  
>  SDK_NAME = "${DISTRO}-${POKYLIBC}-${SDK_ARCH}-${TARGET_ARCH}"
> -SDKPATH = "/opt/${DISTRO}"
> +SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
>  
>  CACHE = "${TMPDIR}/cache/${POKYMODE}-${POKYLIBC}${@['', '/' + str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d, 1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}"
>  

Re: [PATCH 0/1] Enable parallel installations of SDK's from different Poky versions

[Scott Garman]

On 11/19/2010 07:07 AM, Joshua Lock wrote:
> Simple patch to enable multiple SDK installations under the /opt/poky namespace separated into folders matching the version of the corresponding Poky distro release.
>
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>    Branch: josh/sdk
>    Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=josh/sdk
>
> Thanks,
>      Joshua Lock<josh@linux.intel.com>
> ---
>
>
> Joshua Lock (1):
>    poky.conf: move the SDK install into version directories
>
>   meta/conf/distro/poky.conf |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>

NAK. This would potentially break the poky-qemu script, which needs to 
differentiate between whether it is being run with an in-tree Poky setup 
or a standalone toolchain. See how the SDKDIR variable is set in 
poky-qemu-internal.

Mark rightly points out that hardcoded paths to SDK installations is 
kludgy and we need to move toward allowing arbitrary install locations. 
That however is going to take some coordination and edge-case planning 
before we can begin to do the refactoring. Please keep me in the loop on 
those discussions.

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Distro Engineer - Yocto Project

Re: [PATCH 1/1] poky.conf: move the SDK install into versiondirectories

[Tom Rini]

On 11/19/2010 09:38 AM, Mark Hatle wrote:
> As we move beyond 1.0 work.  Would it make sense to focus on making sure the SDK
> tooling works no matter where it is installed?
>
> The compiler/linker can already do this... the other components that may be part
> of the SDK may need some slight changes to detect their current run-time
> location and adjust internal paths as necessary.
>
> (We have experience doing this for Wind River Linux, so we should be able to
> help out if it's a desired feature for Poky.)

It's happily no longer the dark ages.  The biggest hurdle, in oe.dev 
anyhow, is fixing up the helper/environment scripts that get made.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH 1/1] poky.conf: move the SDK install into versiondirectories

[Joshua Lock]

On Fri, 2010-11-19 at 10:38 -0600, Mark Hatle wrote:
> As we move beyond 1.0 work.  Would it make sense to focus on making sure the SDK
> tooling works no matter where it is installed?

It sure would. Theoretically that's already the case we just default to
extracting the SDK to a sane place.

Are you suggesting that we just inflate to a child of cwd and do the leg
work to ensure this *should* work?

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: [PATCH 1/1] poky.conf: move the SDK install into versiondirectories

[Richard Purdie]

On Fri, 2010-11-19 at 10:38 -0600, Mark Hatle wrote:
> As we move beyond 1.0 work.  Would it make sense to focus on making sure the SDK
> tooling works no matter where it is installed?
> 
> The compiler/linker can already do this... the other components that may be part
> of the SDK may need some slight changes to detect their current run-time
> location and adjust internal paths as necessary.
> 
> (We have experience doing this for Wind River Linux, so we should be able to
> help out if it's a desired feature for Poky.)

On the whole I think we're already in very good shape in this regard
since the sstate packages are designed to be relocatable and adapting
this to the sdk tooling isn't hard.

There is however one peculiarity to keep in mind. The packages we build
to populate /opt/poky are "special". How so?

We have to compile them against a libc so we choose to compile them
against one we build ourselves since we can't guarantee that for a given
SDKMACHINE choice, a suitable libc would be available on any given build
machine. This isn't a problem, we have a cross compiling build system
capable for building toolchains so building our own libc is by far the
easiest thing to do. Also, by doing this we guarantee that the binary
will run pretty much anywhere as we have *no* native dependencies to
worry about.

The twist is that by building the libc we build a dyanmic loader too as
the two are bound together. As we cannot install things into /lib*, we
build our libc to live in /opt/poky/sysroots/*/lib. Our libc and dynamic
loader know how to get the search order right for libs. The trouble is
that the path to the dynamic loader is hardcoded into binaries. We want
binaries to find our loader, not the system one as they behave
differently for path search order.

There is no way to specify the dynamic loader path using $$ORIGIN or as
a relative path.

On the positive side, if you have a libc binary you want to drop in
instead of our version and are happy your libc represents a minimum
target requirement such as LSB X.Y then telling Poky to use that instead
of building its own isn't hard. I have seen some nasty corner cases for
the dynamic linker though where you load a system lib which loads a
dependency for which we ship a library of a different version
within /opt/poky (e.g. xrandr). The main binary can then see a version
of the library it wasn't compiled for and there starts a world of pain.

I value Poky's total independence model and it can be adapted to suit
something like an LSB target easily as that is a simplified version
(where you'd have to provide some prebuilt binaries). The downside is
that the dynamic loader location is hardcoded into the binary.

I have been thinking a nice solution would be a redirection loader at
some specified path which would simply transfer execution to the "real"
loader allowing binaries to become relocatable again. The alternative
would be $$ORIGIN support or relative path support for dynamic loaders
but this would require Linux kernel changes and it would hence be a
while before it could be relied upon, even if such a change were
acceptable to mainline.

Cheers,

Richard