[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backward/forward binary compatibility checker

Steve Langasek wrote:
On Fri, Aug 07, 2009 at 04:57:38PM +0400, Andrey Ponomarenko wrote:
2) icheck was intended for the same purposes as an
ABI-compliance-checker, but icheck has many drawbacks:

    c)  icheck contains 467 files and 61 sub-folders;
ABI-compliance-checker is a single file.
I am concerned that you think this is a feature.

I think that tool designed for one simple feature must be in one file.
    d) icheck searches changes in `gcc -E -x c-header header_name.h`
output, that represent a header after preprocessing - it is a very
inconveniently  method because it need a lot of code for parsing header
(about 750 kb of code); ABI-compliance-checker searches differences in
the `gcc -fdump-translation-unit header_name.h` output, that represents
a syntax tree of the header files.
I'm not familiar with -fdump-translation-unit.  Is there any possibility
that ABI-compliance-checker will overlook ABI changes that icheck will
-fdump-translation-unit compiler option provides only more convenient output (syntax tree) for checking compatibility.
Does ABI-compliance-checker's representation of the ABI behave in an
architecture-independent fashion, so that it's possible to draw conclusions
about ABIs on other architectures than the architecture on which you're
running the check?

ABI-compliance-checker's representation of the ABI really depends on architecture. But it is not important. You may transfer all your header files to another host and compare it.
    e) as described in the documentation
(http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
get compatibility report - it is not easy.
I was completely wrong, icheck may generate compatibility report in one run, sorry.
Huh?  You have to have a representation of the baseline ABI to compare
against.  Does ABI-compliance-checker assume that both copies of the header
will be unpacked and available locally at the same time, in order to be able
to do everything in "one run"?  That would be much less useful; we don't
want to have to carry around the actual headers or objects from the
reference version of the library in order to be able to run these tests, we
would want to be able to ship a "manifest" representation of the reference
ABI in our sources to compare against.
You are right, ABI-compliance-checker does not allow such advantages yet. But usually upstream library developers have all installed versions on one host (if not, they may install it), and you may transfer all your header files as well as your "manifest" representation to other host and check it.
In general icheck may be used for checking binary compatibility of C libraries, but it has several drawbacks.

Reply to: