[dpdk-dev] Inter-PMD dependencies when building shared libraries

Bruce Richardson bruce.richardson at intel.com
Thu Oct 5 14:50:17 CEST 2017

On Thu, Oct 05, 2017 at 02:32:06PM +0200, Thomas Monjalon wrote:
> 05/10/2017 14:12, Olivier MATZ:
> > On Mon, Oct 02, 2017 at 08:48:29PM +0000, Eads, Gage wrote:
> > > I believe I've spotted an issue in the way inter-PMD dependencies are handled when building shared libraries. The depdirs_rule in mk/rte.subdir.mk relies on DEPDIRS-xyz containing the names of subdirectories that xyz depends on. In mk/rte.lib.mk, these DEPDIRS are converted into LDLIBS. This works when the subdirectory names match the library names (i.e. any of the libraries under lib/). However when the dependency is on a PMD, the subdirectory and library names don't match.
> [...]
> > To solve this, we can either:
> > 
> > 1- do additional fixes of the "dir name -> lib name" conversion in
> >    lib.mk for all this list above, as we are doing for eal or
> >    ethdev. This looks feasible, but quite ugly.
> > 
> > 2- rename all directories to match the libname (ex: drivers/net/null
> >    becomes drivers/net/librte_pmd_null). Looks to be a bad idea ;)
> > 
> > 3- stop to generate the list of libraries from depdirs: DEPDIRS is
> >    kept for directory dependency at build, and the list of libraries
> >    is advertised in LDLIBS variable, in each Makefile.
> > 
> > My vote would go for option 3.
> We could have several libraries in the same directory.
> So I vote for option 4:
> 4- Replace directory dependencies with library dependencies in makefiles.
>    And convert libs to dirs with an autogenerated table.
> Note: that's why I don't like recursive makefiles like we have
> in the DPDK build system. It forces us to deal with directories
> instead of just declaring dependencies on real file targets.

IF we have time to implement your solution 4, then sure. However, if we
want this fixed for 17.11, I think 3 sounds reasonable.

For option 2, renaming directories to standardise things a bit would be
nice, as it would simplify things a bit for the new meson build system -
I could remove the "name" override value for each lib - but I don't
think it would help much in this case without making things extremely
ugly with using full library names as you suggest.

So I think option 3 or 4 is what is needed.

This should not be a problem using meson build, as libs and drivers are
already tracked using dependency objects across build directories.
However, we do need to ensure that our dependencies are always in the
right order, we can't have a NIC pmd driver depending on a mempool
driver, while another mempool driver depends on a different NIC driver.
We need to be able to scan the driver subdirs in a fixed order and have
all dependencies declared before they are needed.


More information about the dev mailing list