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

Khem Raj raj.khem at gmail.com
Mon Mar 14 17:52:38 UTC 2011


On Sat, Mar 12, 2011 at 4:50 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> 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.
>

Yes thats one way of doing it and if you got it working this is fine
but there were issues when referencing
due to ORIGIN mucking. So this was better and cleaner than we link in
this libs into binary itself.  From
my POV even this solution can be improved by adding the support libs
to gcc build itself as sources
then we dont need to muck with gcc build configury at all. I have been
doing that for non OE related
SDKs and has been best so far.

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

LDFLAGS are modified to get the LDFLAGS into gcc itself otherwise it
would not honour
the modified LDFLAGS to pass -static option.

>
> Cheers,
>
> Richard
>
>




More information about the Openembedded-core mailing list