> 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