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

[Tom Rini]

On Tue, 2010-02-09 at 12:08 -0800, Khem Raj wrote:
> On (08/02/10 12:00), Tom Rini wrote:
> > 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.
> 
> I think the prerequisites of gcc libmpfr, libgmp and libmpc from 4.5
> onwards are probably not used by 
> any other tools we stage for host so it would be safer to build them inside
> gcc tree and link in statically and only create runtime deps on the
> libraries that always exist like libc. This will have better chance of
> relocation. We just need to untar these libraries in top of gcc src tree
> and it will use cofigure and use it. But this only solves gcc issue 
> for other host/cross packages which depend upon libs from staging we still
> need a solution. 

I was thinking that too.  Phil, can you try on your toolchain branch to
do this? :)

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