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