mirror of
git://sourceware.org/git/libabigail.git
synced 2025-03-07 07:07:36 +00:00
The Git repository of the Libabigail Project
Suppose we have tree types which have the same name A. The first A comes from a binary B1 and the two others come from a binary B2. Let's call them A{B1}{1}, A{B2}{1} and A{B2}{2}. Suppose A{B1}{1} is different from A{B2}{1} (but both types are compatible), just because one of their sub-types are different but are compatible. So A{B1}{1} and A{B2}{1} are canonically different; they have different canonical types. But then, because of the One Definition Rule (ODR), A{B2}{1} and A{B2}{2} are canonically equal. But then let's suppose that A{B2}{2} is structurally equal to A{B1}{1}. So this implies that A{B1}{1} and A{B2}{2} are canonically different, while being structurally equal. Odd, but not impossible. I noticed this while comparing the two versions of libgromacs_d.so.0.0.0 involved in the comparison referenced by bug https://bugzilla.redhat.com/show_bug.cgi?id=1283906. But then that library is too big (and takes too much time) to be included as a non regression test :( Anyway, this patch detects this glitch and categorizes it so that the resulting ABI change reports are filtered out. Otherwise, this is considered as an ABI change (because of the canonical different), for which the reporter fails to provide details (because of the structural equality). * src/abg-comp-filter.cc (class_diff_has_harmless_odr_violation_change): New static function. (harmless_filter::visit): Call it. Signed-off-by: Dodji Seketeli <dodji@redhat.com> |
||
---|---|---|
bash-completion | ||
doc | ||
include | ||
m4 | ||
scripts | ||
src | ||
tests | ||
tools | ||
.gitignore | ||
abigail.m4 | ||
AUTHORS | ||
ChangeLog | ||
COMMIT-LOG-GUIDELINES | ||
COMPILING | ||
config.h.in | ||
configure.ac | ||
CONTRIBUTING | ||
COPYING | ||
COPYING-GPLV3 | ||
COPYING-LGPLV2 | ||
COPYING-LGPLV3 | ||
gen-changelog.py | ||
install-sh | ||
libabigail.pc.in | ||
ltmain.sh | ||
Makefile.am | ||
README |
This is the Application Binary Interface Generic Analysis and Instrumentation Library. It aims at constructing, manipulating, serializing and de-serializing ABI-relevant artifacts. The set of artifacts that we are intersted is made of quantities like types, variable, fonctions and declarations of a given library or program. For a given library or program this set of quantities is called an ABI corpus. This library aims at (among other things) providing a way to compare two ABI Corpora (apparently the plural of corpus is copora, heh, that's cool), provide detailed information about their differences, and help build tools to infer interesting conclusions about these differences. You are welcome to contribute to this project after reading the files CONTRIBUTING and COMMIT-LOG-GUIDELINES files in the source tree. Communicating with the maintainers of this project -- including sending patches to be include to the source code -- happens via email at libabigail@sourceware.org.