<snip> > On Thu, Jul 16, 2020 at 3:21 PM Dodji Seketeli <do...@redhat.com> wrote: > > Just for the sake of precision, I'd like to say that in the coming 1.8 > > version of libabigail, this change won't be reported by the tooling as a > > problem anymore. This is thanks to David filing the feature request > > https://sourceware.org/bugzilla/show_bug.cgi?id=25661 a while ago. > > > > Until then, I understand that the current tooling needs to work with > > libabigail 1.6. > > That's what we have in the CI with a 1.6 libabigail compiled in Ubuntu 18.04. > > I tested 20.04 in Travis (I can send a patch later), but it still has > a 1.6 version. > We will have to live with a "not that recent" version for some time. > > > > > > So maybe a more specific suppression rule (that you could still remove > > for the 20.11 stable branch) could look like: > > > > [suppress_type] > > name = rte_mbuf_ext_shared_info > > has_data_member_inserted_between = {offset_of(refcnt_atomic), > offset_of(refcnt_atomic)} > > > > > > It's a "hack" that will only suppress change reports on the > > rte_mbuf_ext_shared_info type if: > > > > 1/ it it has a data member inserted at the > > offset of its data member 'refcnt_atomic', > > > > AND > > > > 2/ the size of rte_mbuf_ext_shared_info doesn't change. > > > > > > There are cases where this won't work, though. But it might work for > > this case. If it does, then great. I think it'd be a better solution > > than a blanket suppression of all the changes on the type. > > Nice, thanks Dodji.
Thanks, David and Dodji. Updated in v5. Thanks, Phil
