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

[Neil Horman]

On Thu, Feb 12, 2015 at 09:17:39AM +0000, Gonzalez Monroy, Sergio wrote:
> 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 at tuxdriver.com]
> >>>Sent: Friday, January 30, 2015 6:13 PM
> >>>To: Gonzalez Monroy, Sergio
> >>>Cc: Thomas Monjalon; dev at 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.
> >>
> >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?
> 
Ah, I see now.  What you're saying is that, in our proposed scenario, a PMD that
requires, say librte_ether, will have a DT_NEEDED entry explicitly for that
library, as opposed to libdpdk_core, is that correct?  If it is, I think thats
ok.  We will still need to have the librte_ether library around, because the
libdpdk_core DSO will reference it on its INPUT line, and in fact it should
already be loaded because of that, rendering the DT_NEEDED entry moot.  That is
to say, and requirements from a PMD codified in a DT_NEEDED entry should already
be satisfied by the application if it properly linked against libdpdk_core.

That said, it should also be safe to remove the DT_NEEDED entry from the PMD for
the same reason (the fact that any dependent libraries should already be loaded
makes it non-useful).

I would personally just leave them in place, as they are harmless, and doing so
is really just more work, but if you want to remove the DT_NEEDED's from the
PMD's it won't hurt anything

Or is there another facet to this that I'm missing?

Best
Neil

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