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

[Tom Rini]

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.

-- 
Tom Rini
Mentor Graphics Corporation