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 <[email protected]> Mentor Graphics Corporation _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
