2015-01-29 11:38, Neil Horman: > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > The idea of core libraries is to group those libraries that are > > always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > > libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > Something occured to me thinking about this patch set. I noticed recently > that > different rules are used to build the shared combined lib from the individual > shared objects. The implication here is that linker options specified in > individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI > versioning script) get ignored, which is bad. Any other file specific linker > options (like <file>_LDFLAGS specified in individual library makefiles are > getting dropped for the combined lib. > > It seems like it would be better if the combined libs were manufactured as > linker scripts themselves (textfiles that used linker directives to include > individual libraries under the covers (see /lib64/libc.so for an example). > > The disadvantage of such an approach are fairly minimal. With such a combined > library, you still need to install individual libraries, but for applications > that wish to link and run against a single dpdk library will still work just > as > they currently do, you can link to just a single library. > > The advantage is clear however. By following a linker script aproach, objects > build as separate libraries are built exactly the same way, using the same > rules > with the same options. It reduces the dpdk build environment size and > complexity, and reduces the opportunity for bugs to creep in from forgetting > to > add build options to multiple locations. It also provides a more granular > approach for grouping files. Creating a dpdk core library becomes a matter of > creating a one line linker script named libdpdk_core.so, rather than > re-arraning > sections of the build system. > > Thoughts?
Neil, it seems to be a good idea. I like the idea of making things simpler ;) -- Thomas