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

[Khem Raj <raj.khem@gmail.com>]

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. 

-Khem


> 
> -- 
> Tom Rini <tom_rini@mentor.com>
> Mentor Graphics Corporation
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel