On Wed, 2010-02-10 at 15:50 +0000, Richard Purdie wrote: > On Tue, 2010-02-09 at 14:36 -0700, Tom Rini wrote: > > On Tue, 2010-02-09 at 12:08 -0800, Khem Raj wrote: > > > On (08/02/10 12:00), Tom Rini wrote: > > > 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? :) > > Another generic solution I'm wondering about is postprocessing the > cross/native binaries with chrpath. This has the benefits of no horrible > shell quoting and its generic.
Yeah, either that or wrapping the binaries in something (either a binayr or just a shell script) which invokes the dynamic linker with an appropriate library path. That would also handle your situation where you have a custom ld.so as well. p. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
