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

[Gonzalez Monroy, Sergio]

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

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

Thoughts?

Regards,
Sergio