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

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Feb 11, 2015 at 11:11:13AM +0000, 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.
> 
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?

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