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

[Richard Purdie <rpurdie@linux.intel.com>]

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