[OE-core] [PATCHv3 3/6] gcc: Statically link in support libraries e.g. libmpfr libgmp etc.

[Richard Purdie]

On Tue, 2011-03-15 at 10:33 -0700, Tom Rini wrote:
> On 03/14/2011 12:54 PM, Richard Purdie wrote:
> > On Mon, 2011-03-14 at 09:50 -0700, Tom Rini wrote:
> >> On 03/12/2011 05:50 AM, Richard Purdie wrote:
> >>> On Tue, 2011-03-08 at 11:04 -0800, Khem Raj wrote:
> >>>> On Tue, Mar 8, 2011 at 10:53 AM, Richard Purdie
> >>>> <richard.purdie at linuxfoundation.org>   wrote:
> >>>>> On Mon, 2011-03-07 at 22:38 -0800, Khem Raj wrote:
> >>>>>> ping any opinion on this patch ?
> >>>>>
> >>>>> This change looks rather hacky and I'd really like to understand more
> >>>>> about why this is needed and whether there is a better way we could
> >>>>> ensure the right flags get passed around. Can you provide more details
> >>>>> about whats going on with this. Obviously this change as it stands isn't
> >>>>> acceptable to upstream gcc and I'd like to see if we could find one that
> >>>>> was.
> >>>>
> >>>> this is because the supporting libraries like mpc mpfr that are needed
> >>>> by gcc itself to run
> >>>> we might have different versions of these libraries. So depending upon
> >>>> shared objects
> >>>> would mean we need to find same shared objects where say the SDK is installed
> >>>> so either we ship the whole baggage or we link it in statically. This
> >>>> patch makes those libs to
> >>>> linked in statically and cross gcc wont have dependencies on these
> >>>> libs anymore so
> >>>> it can run on all hosts pretty much.
> >>>
> >>> If you look at the way the SDK toolchain works in Poky, it automatically
> >>> ships the versions of these libraries that it needs so we don't actually
> >>> have this problem.
> >>>
> >>> Also, looking at the patch again, was the first LDFLAGS change meant to
> >>> be in there, is that related or different to the shared/static
> >>> mpfr/mpc/gmp issue?
> >>
> >> I think it's time for someone to build one at dig at it, but are you
> >> sure they're used and shipped and not just used?  That was a problem
> >> before and unless the exported bits are using a relative $ORIGIN in the
> >> link path (or we've broken relocatability, which would be another
> >> problem) there's problems today.
> >
> > They are used and shipped. As evidence I submit:
> >
> > http://autobuilder.yoctoproject.org/nightly/20110311-1/toolchain/x86_64/poky-lsb-eglibc-x86_64-i586-toolchain-gmae-0.9+snapshot-20110313.tar.bz2
> 
> Is 
> /opt/poky-lsb/0.9+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc 
> the runs on host targets the target cross compiler the user should use 
> now?  If so, you don't have relocation as the RPATH is hard-coded not 
> $ORIGIN based.  If not, can I have a pointer to the right gcc to poke 
> at?  Thanks :)

Hmm, this sounds like something is not working with the relocation. I
could have sworn we'd made that relocatable :/.

It shouldn't be hard to fix with the relocation class at least...

I hope we at least agree it does find the right libraries to link
against which is most of the problem solved :)

Cheers,

Richard