On Fri, Jan 17, 2020 at 8:02 PM Neil Horman <nhor...@tuxdriver.com> wrote: > Hmmm....I wonder if its worth orchestrating the build system to use a git > submodule storing whatever our CI system can produce and using it as a cache, > and falling back to a local build if the appropriate arch isn't found? That > might offer some incentive to alternate arch maintainers to contribute > hardware > or compute time to populating it in pursuit of better build times?
Thomas, Neil, I would prefer we consider this in a second step. Just want to give a little update on this patch. Building dpdk with debuginfo seems necessary, if we want to catch internal structures changes. I suppose Bruce patch can be merged already: https://patchwork.dpdk.org/patch/63400/ libabigail in Ubuntu 16.04 (Xenial) is a bit old (version 1.0-rc3) and exhibits a false positive on the linkage name of the default symbol if we do function versioning: we caught this with Olivier when he asked for help on his patch for mempool. This issue disappears with version 1.2 that is in Ubuntu 18.04 (Bionic). After running the check in my environment (fc30 with libabigail 1.5), I caught issues with abidiff when comparing a .so and an abi dump. I reported this upstream, and Dodji fixed this right away. https://sourceware.org/bugzilla/show_bug.cgi?id=25409 The fix should be part of version 1.7. This could be ignored if we only do the checks with binaries generated with gcc. I just got a false positive on an ABI change for the "custom element size" ring series, but on a type that is not user visible (thanks Honnappa). So this needs more work: I hope the --headers-dirX options will help but it means we must store the public headers with the ABI dumps. I can prepare a v2 and have the CI only warns about changes without reporting a failure. -- David Marchand
