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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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