[dpdk-dev] [PATCH v3 3/6] mk: sort libraries when linking, move pmd libs to higher level

[Ferruh Yigit]

On 6/13/2016 11:21 AM, Thomas Monjalon wrote:
> 2016-06-13 11:04, Ferruh Yigit:
>> On 6/13/2016 10:29 AM, Thomas Monjalon wrote:
>>> 2016-06-10 19:32, Ferruh Yigit:
>>>> As stated in the comment:
>>>>     Order is important: from higher level to lower level
>>>>
>>>> This is an attempt to make the layering order better respected.
>>>>
>>>> Limit scope of --whole-archive to pmd libraries
>>>
>>> Compared to the link order in the v2, you did two things:
>>> 1/ move PMDs to the first position
>>> 2/ restrict --whole-archive to PMDs only
>>>
>>> Having the PMDs first, helps the linker to get all the PMD dependencies
>>> in the static binary. Thus it seems we do not need --whole-archive
>>> for the PMD dependencies (ethdev, mbuf, etc).
>>> But, if an external PMD is loaded via dlopen, it is possible that it
>>> needs a symbol which was not used by the internal PMDs. So it will not
>>> be found in the statically linked binary.
>>> Let's take another example: if we disable the internal PMDs with their
>>> config options from the static build, and we decide to build them
>>> separately as DSOs. We won't be able to load them as plugins because
>>> they depend on symbols which won't be found in the static binary.
>>
>> So you want to keep all objects in final binary (used or unused) because
>> of the possibility that any plugin may use them.
> 
> Yes
> 
>> But what is the list to include here, whole dpdk?, -since we may not
>> know what API will plugin call.
> 
> The list of the libraries candidates to be called from a driver can be
> discussed. The top layers like lpm or distributor should not be in this
> list I think.
> 
>> What I am confused is --whole-archive only used when dpdk compiled as
>> static, if dpdk compiled as shared, each PMD should have proper
>> dependencies [1], and if external PMD compiled properly there shouldn't
>> be a problem. So do we have a case that dpdk compiled statically into
>> final binary but we still want to load some plugins dynamically?
> 
> Yes a plugin can be loaded from a static binary.
> Breaking this feature would need a separate discussion and notices.
Thanks for clarifying, I wasn't aware of this.
So I am leaving this patch, please just ping if anything required from me.

> 
>>> To make it short, the PMDs must be considered as plugins. Therefore, we
>>> must not rely on their availability to link the required symbols in
>>> a static binary.
>>> To make sure the plugin loading will be always well achieved, we must
>>> link the static PMDs at the last position.
>>
>> I think this is not the issue of linking PMD's first or last, but
>> expanding --whole-archive to cover other libraries other than PMDs.
> 
> Yes, linking PMD at the end is a way to force us to keep some libraries
> in --whole-archive.
> 
>>> If you agree, I vote for the v2 of this patchset.
>>
>> If this is breaking something and best way to fix is not in external PMD
>> but in here, please feel free to go with v2.
> 
> I don't see any other solution.
> But I'm sure we could discuss it more and/or improve it in the future.
>