On Wed, Dec 4, 2019 at 12:56 PM Neil Horman [off-list ref] wrote:

On Wed, Dec 04, 2019 at 09:47:31AM +0100, David Marchand wrote:

quoted

On Tue, Dec 3, 2019 at 4:27 PM Laatz, Kevin [off-list ref] wrote:

quoted

quoted

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.

Ah ah.. yes.
^U on this idea.


-- 
David Marchand