[dpdk-dev] [PATCH 00/17] build DPDK libs and some drivers with meson/ninja

Bruce Richardson bruce.richardson at intel.com
Tue Sep 12 14:55:31 CEST 2017

On Mon, Sep 04, 2017 at 02:23:13PM +0100, Van Haaren, Harry wrote:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
> > Richardson Sent: Friday, September 1, 2017 11:04 AM To: dev at dpdk.org
> > Cc: Richardson, Bruce <bruce.richardson at intel.com> Subject:
> > [dpdk-dev] [PATCH 00/17] build DPDK libs and some drivers with
> > meson/ninja
> > 
> > Following on from the two previous RFCs [1] [2], here is a cleaned
> > up patchset to serve as a start-point for getting all of DPDK
> > building with meson and ninja.
> > 
> > What's covered: * Basic infrastructure for feature detection and
> > DPDK compilation * Building of all DPDK libraries - as either static
> > or shared * Compilation of igb_uio driver for Linux * Building a
> > number of mempool, crypto and net drivers.  * Installation of
> > compiled libraries and headers * Installation of usertools scripts *
> > Compilation of testpmd as dpdk-testpmd and install of same *
> > Generation and installation of pkgconfig file for DPDK *
> > Contributors guide document addition describing how to add build
> > scripts
> > 
> > What's not implemented: * Just about everything else :-), including
> > * Support for non-x86 architectures, including cross-compilation *
> > Lots of PMDs * Support for building and running the unit tests
> > 
> > Some key differences from RFC2: * Removed duplication between the
> > different driver meson files by moving the build logic up one level
> > to the driver/meson.build file.  * Added a build option to allow
> > versioning the libraries using the DPDK version number, rather than
> > individual .so versions.  * Made EAL a default dependency for libs,
> > to simplify meson.build files for a number of them.  * Made the
> > build variables used for libraries and drivers more consistent.  *
> > Moved responsibility for determining if a given driver or library
> > should be built to the driver/library's own build file, giving a
> > single place where all details about that component are placed, and
> > saving having lots of environment detection logic in higher-level
> > build files.  * Begun adding in developer documentation to make it
> > easier for driver authors/maintainers to contribute.
> > 
> > Meson 0.41 and ninja are needed, and ideally meson 0.42 is
> > recommended.  Ninja is available in most distributions, and meson -
> > if an updated version is not available on your distro of choice -
> > can be easily got using "pip3 install meson"
> > 
> > To build and install then use:
> > 
> > 	meson build # use default compiler and shared libs cd build
> > 	ninja sudo ninja install
> > 
> > Thereafter to use DPDK in other build systems one can use:
> > 
> > 	pkg-config --cflags DPDK pkt-config --libs DPDK
> > 
> > to query the needed DPDK build parameters.
> > 
> > Once reviewed and tested a bit, I hope to apply this set - or a new
> > revision of it - to the build-next tree, to serve as a baseline for
> > others to use and to add the missing functionality to.
> <snip> git / file stats
> A good start - applied cleanly and compiled fine on dpdk-next-build
> tree.
> Some notes from experience of testing on an Ubuntu 16.04 system: -
> libpcap wasn't detected successfully - on researching the transitional
> package "libpcap-dev" was installed, but that didn't actually install
> any of the required files. Installing "libpcap0.8-dev" enabled pcap to
> be detected successfully. No fault of Meson or these patches,  just an
> inconsistency in transitional-packages it seems.
> - Binaries after a compile are in a different location (compared to mk
> build system). eg: testpmd now resides in app/test-pmd/dpdk-testpmd.
> No issue, just a note that the path to the binaries changes. With the
> very-easy "ninja install" and "ninja uninstall", dpdk applications can
> just be run directly from the installed location (assuming binaries
> placed on PATH).
> - Ninja install is required with shared-object builds, to enable the
> dpdk binary (eg: testpmd) to find the .so objects. Doing a local
> compile (without install) and running ./app/test-pmd/dpdk-testpmd
> will print "MBUF: error setting mempool handler" and rte_panic(). This
> is obviously not an issue for static builds - the functionality is
> linked into the application in that case. 
Actually, some further clarification on this last item.

It's not the .so's that are regular libraries that are the problem, just
the drivers.  As part of the build, meson configures the binaries'
rpaths so that they record the paths to their library dependencies,
which means that the binaries are indeed runable in the build directory.
(These build rpaths are replaced on install). This is why you get a DPDK
error, not a loader error. 

In our case, we don't link the driver libraries against the binaries,
but expect them to be loaded via "-d" flag to eal, so the required rpath
values for those drivers are not configured, and the drivers are not
placed in $DPDK_DRIVER_PATH until the install step.

So this means that the binaries *are* in fact runable from the build
directory, just not as easily as after install, as you have to manually
pass in a -d flag to force the loading of all drivers required -
mempool, NIC, etc.


More information about the dev mailing list