Re: [dpdk-dev] [PATCH v3 0/7] Add ABI compatibility checks to the meson build

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Dec 04, 2019 at 09:47:31AM +0100, David Marchand wrote:
> On Tue, Dec 3, 2019 at 4:27 PM Laatz, Kevin <kevin.laatz@intel.com> wrote:
> > > Build targets in project: 1019
> > > WARNING: Project specifies a minimum meson_version '>= 0.47.1' but
> > > uses features which were added in newer versions:
> > >   * 0.48.0: {'console arg in custom_target'}
> > >   * 0.50.0: {'install arg in configure_file'}
> > > Found ninja-1.9.0 at /usr/bin/ninja
> > > ninja -C /home/dmarchan/builds/build-gcc-static
> > > ninja: Entering directory `/home/dmarchan/builds/build-gcc-static'
> > > [48/2291] Generating librte_kvargs.abi_chk with a meson_exe.py custom command.
> > > FAILED: lib/librte_kvargs.abi_chk
> > > /usr/bin/meson --internal exe
> > > /home/dmarchan/builds/build-gcc-static/meson-private/meson_exe_abidiff_6511538ddd95d9672028017110fa45c67f01f7be.dat
> > > file /home/dmarchan/dpdk/lib/abi/librte_kvargs.dump does not exist
> > > [77/2291] Compiling C object
> > > 'lib/76b5a35@@rte_mbuf@sta/librte_mbuf_rte_mbuf.c.o'.
> > > ninja: build stopped: subcommand failed.
> >
> > This is failing as the .dump files have not been created yet. They can
> > be generated with devtools/gen-abi-dump.sh <build_dir>. This will
> > generate a .dump file for each shared object in the builddir drivers and
> > lib folders.
> 
> Throwing an idea, I did not investigate.
> 
> Could we refactor our tools/checks on the .map files to use the dump files?
> We would then only maintain one file about symbols versioning.
> 
Thats a chicken and egg problem.  The map file is the canonical source for
versioning information. Any information that is encoded in the output of objdump
regarding versioning is sourced from the map files, so while you could use the
objdump output to check versioning, you can't remove the need for map files to
encode it.

If you want to remove the map files, we would need to look at the creation of
macros to encode versioning information for each symbol you want to export, and
use that to dynamically build a version map file (simmilar to what the linux
kernel EXPORT_SYMBOL does).  But that just moves version tracking around, it
doesn't really eliminate it.

Neil

> 
> -- 
> David Marchand
> 
>