[oe] [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Tom Rini]

On Sat, 2010-02-06 at 13:04 +0000, Phil Blundell wrote:
> On Thu, 2010-02-04 at 11:57 -0600, Tom Rini wrote:
> > On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > > On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> > > > Does this really make the SDK relocatable? I thought there were still
> > > > major issues with relocating GCC.
> > > 
> > > GCC built from OE may still have relocation problems - haven't checked lately.
> > > But it doesn't mean that's the only use case scenario... There is also 
> > > external toolchain option, as well as building SDK without the toolchain.
> > > Both of those cases were tested with the above change for several months now.
> > 
> > The hard part is that in some distributions you will have libmpfr.so &
> > co if you have a host gcc, and on some you won't.  That in turn makes
> > gcc relocatable or not.  Everything else is handleable via --sysroot=.
> 
> What exactly is the problem with libmpfr?  I would have thought you
> could just ship libmpfr.so.6 inside the sysroot and link gcc against
> that local copy (via -rpath $ORIGIN...), without using the system
> library at all.

I hesitate to say this, since I haven't fully poked the other side of
the equation, but..  With $ORIGIN, you need I think 3 levels of
checking-back since cc1 (& others) need libmpfr.  That, mixed with just
how ugly the $ORIGIN stuff gets for gcc, is the problem.  Why you don't
always see the problem is that Ubuntu uses libmpfr.so for its gcc,
RHEL4Usomething (half I haven't checked into personally and so hesitate)
seems to not.

For gcc-cross-sdk, this isn't so much of an issue.  For gcc-cross and
$ORIGIN it gets ugly, but solvable.

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation