Re: [dpdk-dev] [PATCH 0/8] Improve build process

["Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>]

On 12/02/2015 09:22, Panu Matilainen wrote:
> On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote:
>>> From: Neil Horman [mailto:nhorman@tuxdriver.com]
>>> Sent: Friday, January 30, 2015 6:13 PM
>>> To: Gonzalez Monroy, Sergio
>>> Cc: Thomas Monjalon; dev@dpdk.org
>>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process
>>>
>>> On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio 
>>> wrote:
>>
>> [snip]
>>
>>>>
>>>> So would it be reasonable to add DT_NEEDED entries to all DPDK 
>>>> libraries
>>> but EAL?
>>>> If I understood what you were saying right, we could enforce the
>>>> 'dependency' in the linker script with something like this:
>>>> $ cat  librte_eal.so
>>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such
>>>> linker script for librte_eal.so instead of the soft link once
>>>> versioning is in place.
>>>>
>>> Correct.
>>>
>>>> Things that would be missing versus the proposed patch:
>>>>   - As I have mention in previous post, ldd info for EAL library 
>>>> would not
>>> reflect
>>>>     its dependency to other DPDK libs.
>>> librte_eal.so would no show those dependencies, as far as I know 
>>> (though I
>>> haven't explicitly checked).  The subordunate libraries included in 
>>> the input
>>> line, may or may not show dependencies among themselves, depending on
>>> your build setup (and the use of --no-as-needed and -l when linking the
>>> individual .so libraries.
>>>
>>>>   - I was enforcing resolving all references when building the 
>>>> libraries (-z
>>> defs), so
>>>>     we either remove it altogether or skip eal.
>>> I think thats correct, yes.
>>>
>>>>   - All apps would show DT_NEEDED entries for a set of DPDK 
>>>> libraries that
>>>>     in most cases are required (eal, mempool, malloc, mbuf, ring VS
>>>> dpdk_core)
>>>>
>>> I think apps linked to libdpdk_core would have DT_NEEDED entries for
>>> libdpdk_core, not the subordonate libraries (though check me on that 
>>> to be
>>> sure).
>>>
>> Just checked on this and they do link against the subordinate 
>> libraries, although
>> It does not really matter as we are dropping the 'core' library 
>> approach anyway.
>>
>>>> I think that the linker script approach is reasonable if we prefer to
>>>> go that way instead of creating a core library.
>>>>
>>> I think it would make sense from a build environment point of view, 
>>> in that it
>>> allows library specific flags to be incorporated properly.  I think 
>>> the only
>>> downside is that the individual libraries still need to be carried 
>>> around
>>> (though they can be ignored from an application build/run standpoint).
>>> You're question should probably be asked of people using COMBINED_LIBS
>>> currently to make sure that meets their needs, though I think it will.
>>>
>>> Neil
>>>
>> So I just realized that I was not having into account a possible 
>> scenario, where
>> we have an app built with static dpdk libs then loading a dso with 
>> -d  option.
>>
>> In such case, because the pmd would have DT_NEEDED entries, dlopen 
>> will fail.
>> So to enable such scenario we would need to build PMDs without DT_NEEDED
>> entries.
>
> Hmm, for that to be a problem you'd need to have the PMD built against 
> shared dpdk libs and while the application is built against static 
> dpdk libs. I dont think that's a supportable scenario in any case.
>
> Or is there some other scenario that I'm not seeing?
>
>     - Panu -
>
I agree with you. I suppose it comes down to, do we want to support such 
scenario?

 From what I can see, it seems that we do currently support such 
scenario by building dpdk apps against all static dpdk libs using 
--whole-archive (all libs and not only PMDs).
http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8

Am I misunderstanding this?

Regards,
Sergio