Re: [PATCH 0/8] Improve build process

["Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On 12/02/2015 05:41, Neil Horman wrote:
> On Wed, Feb 11, 2015 at 11:11:13AM +0000, Gonzalez Monroy, Sergio wrote:
>>> From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org]
>>> Sent: Friday, January 30, 2015 6:13 PM
>>> To: Gonzalez Monroy, Sergio
>>> Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.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.
>>
> ok, understood.
>
>>>> 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.
>>
> This is very true, but I was under the impression that the only things that were
> dlopen-able were PMD's, which would not be part of the core library.  Was I
> mistaken?
As far as I know you are right that only PMDs are being dlopen.
The proposed patch though, added DT_NEEDED entries for PMDs too, so they 
would need to be
left empty for them to work in such scenario.

Is that reasonable?

Regards,
Sergio
>> 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.
>>
>> Thoughts?
>>
> As I mentioned above I thought the only thing that would typically be referenced
> via dlopen would be libraries that were not part of the unified core library.
> if thats not the case, then yes, we need a little more thought here
> Neil
>
>> Regards,
>> Sergio
>>