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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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@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

which I just inspected and it contains libmpc, libgmp and libmpfr.

If it doesn't work, I'd like someone to demonstrate the bug :)

Jsut to be clear, there is *one* hardcoded assumption in the way
nativesdk works which is to do with the dynamic loader location. If we
can link things against some generic common denominator ld.so (likely
from LSB?), it should be possible to remove that limitation. Its always
been intended to add that, just nobody has done it yet. 

Cheers,

Richard