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
> catch?
>
-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.
>
> Cheers,
>
In general icheck may be used for checking binary compatibility of C
libraries, but it has several drawbacks.
