Who uses abi-compliance-checker?

[Richard Shaw]

I initially got abi-compliance-checker into Fedora because one of my
packages does not maintain any sort of API/ABI compatibility or even
versioning for that matter. That way I could always check a new release to
see if any of its dependencies needed to be rebuilt.

Since then, I've started using it for all of my libraries in the spirit of
"Trust but verify", and I've occasionally found issues even though upstream
didn't bump the soversion.

So out of curiosity, anyone else using this great tool?

If anyone is curious about it, I don't mind typing up the process I go
through to make the checks. I think I've found a pretty good path of least
resistance method :)

Thanks,
Richard

[Sérgio Basto]

On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote: 
>  I initially got abi-compliance-checker into Fedora because one of my
>  packages does not maintain any sort of API/ABI compatibility or even
>  versioning for that matter. That way I could always check a new
>  release to see if any of its dependencies needed to be rebuilt.
>  
>  
>  Since then, I've started using it for all of my libraries in the
>  spirit of "Trust but verify", and I've occasionally found issues even
>  though upstream didn't bump the soversion.
>  
>  
>  So out of curiosity, anyone else using this great tool?
>  
>  
>  If anyone is curious about it, I don't mind typing up the process I go
>  through to make the checks. I think I've found a pretty good path of
>  least resistance method :) 
could we use this tool on x264/ffmpeg/mplayer packages ? 
>   

-- 
Sérgio M. B.

[Richard Shaw]

On Wed, Jul 3, 2013 at 4:33 PM, Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
>  > I initially got abi-compliance-checker into Fedora because one of my
>  > packages does not maintain any sort of API/ABI compatibility or even
>  > versioning for that matter. That way I could always check a new
>  > release to see if any of its dependencies needed to be rebuilt.
>  >
>  >
>  > Since then, I've started using it for all of my libraries in the
>  > spirit of "Trust but verify", and I've occasionally found issues even
>  > though upstream didn't bump the soversion.
>  >
>  >
>  > So out of curiosity, anyone else using this great tool?
>  >
>  >
>  > If anyone is curious about it, I don't mind typing up the process I go
>  > through to make the checks. I think I've found a pretty good path of
>  > least resistance method :)
>
>  could we use this tool on x264/ffmpeg/mplayer packages ?
>  
Yes, I'm trying it out, but it looks like there's some windows only headers
installed trying to include d3d9.h which are tripping it up...

Richard

[Richard Shaw]

This is an extreme example, but after removing the offending headers I got
this:

https://dl.dropboxusercontent.com/u/34775202/compat_reports/ffmpeg/0.10.7...

Thanks,
Richard

[Andrey Ponomarenko]

Richard Shaw wrote:
>  This is an extreme example, but after removing the offending headers
> I 
>  got this:
>
>
> https://dl.dropboxusercontent.com/u/34775202/compat_reports/ffmpeg/0.10.7...
>
>  Thanks,
>  Richard
>  
New approach (by using the abi-dumper tool) avoids such problems with 
compiling header files. But if you are using basic approach then you can 
take the input XML descriptor from the appropriate upstream-tracker page 
(push on the "show log" button to extend the content of descriptors):

   http://upstream-tracker.org/versions/ffmpeg.html

-- 
Andrey Ponomarenko, ROSA Lab.

[Andrey Ponomarenko]

Sérgio Basto wrote:
>  On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
> > I initially got abi-compliance-checker into Fedora because one of my
> > packages does not maintain any sort of API/ABI compatibility or even
> > versioning for that matter. That way I could always check a new
> > release to see if any of its dependencies needed to be rebuilt.
> >
> >
> > Since then, I've started using it for all of my libraries in the
> > spirit of "Trust but verify", and I've occasionally found issues even
> > though upstream didn't bump the soversion.
> >
> >
> > So out of curiosity, anyone else using this great tool?
> >
> >
> > If anyone is curious about it, I don't mind typing up the process I go
> > through to make the checks. I think I've found a pretty good path of
> > least resistance method :)
>  could we use this tool on x264/ffmpeg/mplayer packages ? 
See results of analysis for ffmpeg here:

   http://upstream-tracker.org/versions/ffmpeg.html

-- 
Andrey Ponomarenko, ROSA Lab.

[Xavier Bachelot]

On 07/03/2013 10:03 PM, Richard Shaw wrote:
>  I initially got abi-compliance-checker into Fedora because one of my
> packages
>  does not maintain any sort of API/ABI compatibility or even versioning for that
>  matter. That way I could always check a new release to see if any of its
>  dependencies needed to be rebuilt.
>  
>  Since then, I've started using it for all of my libraries in the spirit of
>  "Trust but verify", and I've occasionally found issues even though
> upstream
>  didn't bump the soversion.
>  
>  So out of curiosity, anyone else using this great tool?
>  
I'm not using abi-compliance-checker by itself but through the pkgdiff
wrapper.
I agree this tool is very helpful.

Regards,
Xavier

[Paulo César Pereira de Andrade]

IBook. 'Kiomjm
Em 03/07/2013 19:00, "Xavier Bachelot" <xavier(a)bachelot.org&gt; escreveu:

>  On 07/03/2013 10:03 PM, Richard Shaw wrote:
>  > I initially got abi-compliance-checker into Fedora because one of my
>  packages
>  > does not maintain any sort of API/ABI compatibility or even versioning
>  for that
>  > matter. That way I could always check a new release to see if any of its
>  > dependencies needed to be rebuilt.
>  >
>  > Since then, I've started using it for all of my libraries in the spirit
>  of
>  > "Trust but verify", and I've occasionally found issues even though
>  upstream
>  > didn't bump the soversion.
>  >
>  > So out of curiosity, anyone else using this great tool?
>  >
>  I'm not using abi-compliance-checker by itself but through the pkgdiff
>  wrapper.
>  I agree this tool is very helpful.
>
>  Regards,
>  Xavier
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Sérgio Basto]

On Qui, 2013-07-04 at 00:00 +0200, Xavier Bachelot wrote: 
>  On 07/03/2013 10:03 PM, Richard Shaw wrote:
>  > I initially got abi-compliance-checker into Fedora because one of my packages
>  > does not maintain any sort of API/ABI compatibility or even versioning for that
>  > matter. That way I could always check a new release to see if any of its
>  > dependencies needed to be rebuilt.
>  > 
>  > Since then, I've started using it for all of my libraries in the spirit of
>  > "Trust but verify", and I've occasionally found issues even though
> upstream
>  > didn't bump the soversion.
>  > 
>  > So out of curiosity, anyone else using this great tool?
>  >
>  I'm not using abi-compliance-checker by itself but through the pkgdiff wrapper.
>  I agree this tool is very helpful. 
pkgdiff and abi-compliance-checker seems to be a very cool tool,
unfortunately now, I'm very busy and haven't time to investigate
further, or just to follow this thread ... 
anyway IIRC I think that what Nicolas (kwizart) ask for when we want
bump soname on ffmpeg and others packages etc ...   So maybe this is
interesting for rpmfusion  . 

-- 
Sérgio M. B.

[Andrey Ponomarenko]

Xavier Bachelot wrote:
>  On 07/03/2013 10:03 PM, Richard Shaw wrote:
> > I initially got abi-compliance-checker into Fedora because one of my packages
> > does not maintain any sort of API/ABI compatibility or even versioning for that
> > matter. That way I could always check a new release to see if any of its
> > dependencies needed to be rebuilt.
> >
> > Since then, I've started using it for all of my libraries in the spirit of
> > "Trust but verify", and I've occasionally found issues even though
> upstream
> > didn't bump the soversion.
> >
> > So out of curiosity, anyone else using this great tool?
> >
>  I'm not using abi-compliance-checker by itself but through the pkgdiff wrapper.
Starting with 1.6 version of pkgdiff if you compare debug packages and 
add --details option on the command line then the tool will 
automatically run abi-dumper to dump ABI of old and new shared objects 
found in the packages and then compare them by the 
abi-compliance-checker tool.

>  I agree this tool is very helpful. 
-- 
Andrey Ponomarenko, ROSA Lab.

[Sérgio Basto]

On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:
>  Starting with 1.6 version of pkgdiff if you compare debug packages
>  and 
>  add --details option on the command line then the tool will 
>  automatically run abi-dumper to dump ABI of old and new shared
>  objects 
>  found in the packages and then compare them by the 
>  abi-compliance-checker tool. 

hum , so pkgdiff -details doesn't use abi-compliance-checker without
abi-dumper installed ? 


pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
ERROR: cannot find ABI Dumper
reading packages ...
comparing packages ...
creating changes report ...
result: CHANGED (18.4%)
see detailed report:

pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html


-- 
Sérgio M. B.

[Andrey Ponomarenko]

Sérgio Basto wrote:
>  On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:
> > Starting with 1.6 version of pkgdiff if you compare debug packages
> > and
> > add --details option on the command line then the tool will
> > automatically run abi-dumper to dump ABI of old and new shared
> > objects
> > found in the packages and then compare them by the
> > abi-compliance-checker tool.
>
>  hum , so pkgdiff -details doesn't use abi-compliance-checker without
>  abi-dumper installed ? 
Yes, it doesn't. Detailed checks of ABI changes in shared objects will 
be disabled in this case. They are enabled only if you install both 
tools and compare appropriate debug-info RPM packages.

>  pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
>  x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
>  ERROR: cannot find ABI Dumper
>  reading packages ...
>  comparing packages ...
>  creating changes report ...
>  result: CHANGED (18.4%)
>  see detailed report:
>
>
> pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
>
>  
-- 
Andrey Ponomarenko, ROSA Lab.

[Sérgio Basto]

On Qui, 2013-07-11 at 12:49 +0400, Andrey Ponomarenko wrote: 
>  Sérgio Basto wrote:
>  > On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:
>  >> Starting with 1.6 version of pkgdiff if you compare debug packages
>  >> and
>  >> add --details option on the command line then the tool will
>  >> automatically run abi-dumper to dump ABI of old and new shared
>  >> objects
>  >> found in the packages and then compare them by the
>  >> abi-compliance-checker tool.
>  >
>  > hum , so pkgdiff -details doesn't use abi-compliance-checker without
>  > abi-dumper installed ?
>  
>  Yes, it doesn't. Detailed checks of ABI changes in shared objects will 
>  be disabled in this case. They are enabled only if you install both 
>  tools and compare appropriate debug-info RPM packages. 
ah ABI Status, just appears when we compare debuginfo packages (with
-details )  


>  >
>  >
>  > pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
>  > x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
>  > ERROR: cannot find ABI Dumper
>  > reading packages ...
>  > comparing packages ...
>  > creating changes report ...
>  > result: CHANGED (18.4%)
>  > see detailed report:
>  >
>  >
> pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
Total Objects (with debug-info) 2 
ABI Compatibility 70.8%


Cool thanks, 

pkgdiff print some errors [1] are you interested in reports ? 


[1] pkgdiff x264-debuginfo-0.130-3.20130502git1db4621.fc20.i686.rpm
x264-debuginfo-0.133-1.20130709git585324f.fc20.i686.rpm -details
reading packages ...
comparing packages ...
Compare ABIs of x264 (0.8M) ...
ERROR: missed type id 130179
ERROR: missed type id 131954
ERROR: missed type name (82925)
ERROR: missed type id 23828
ERROR: missed type id 132137
ERROR: missed type id 47285
ERROR: missed type id 47358
ERROR: missed type id 6333
ERROR: missed type id 134805
ERROR: missed type id 131958
ERROR: missed type id 134661
Compare ABIs of libx264.so.130 (2.3M) ...
ERROR: Failed to run ABI Compliance Checker (7)
Compare ABIs of libx26410b.so.130 (2.2M) ...
ERROR: Failed to run ABI Compliance Checker (7)
Compare ABIs of libx264.so.130 (2.4M) ...
ERROR: missed type id 36143
creating changes report ...
result: CHANGED (97.1%)
see detailed report:

pkgdiff_reports/x264-debuginfo/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html


-- 
Sérgio M. B.

[Andrey Ponomarenko]

Sérgio Basto wrote:
>  On Qui, 2013-07-11 at 12:49 +0400, Andrey Ponomarenko wrote:
> > Sérgio Basto wrote:
> >> On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:
> >>> Starting with 1.6 version of pkgdiff if you compare debug packages
> >>> and
> >>> add --details option on the command line then the tool will
> >>> automatically run abi-dumper to dump ABI of old and new shared
> >>> objects
> >>> found in the packages and then compare them by the
> >>> abi-compliance-checker tool.
> >> hum , so pkgdiff -details doesn't use abi-compliance-checker without
> >> abi-dumper installed ?
> > Yes, it doesn't. Detailed checks of ABI changes in shared objects will
> > be disabled in this case. They are enabled only if you install both
> > tools and compare appropriate debug-info RPM packages.
>  ah ABI Status, just appears when we compare debuginfo packages (with
>  -details )
>
>
> >>
> >> pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
> >> x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
> >> ERROR: cannot find ABI Dumper
> >> reading packages ...
> >> comparing packages ...
> >> creating changes report ...
> >> result: CHANGED (18.4%)
> >> see detailed report:
> >>
> >>
> pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
>  Total Objects (with debug-info) 2
>  ABI Compatibility 70.8%
>
>
>  Cool thanks,
>
>  pkgdiff print some errors [1] are you interested in reports ?
>
>
>  [1] pkgdiff x264-debuginfo-0.130-3.20130502git1db4621.fc20.i686.rpm
>  x264-debuginfo-0.133-1.20130709git585324f.fc20.i686.rpm -details
>  reading packages ...
>  comparing packages ...
>  Compare ABIs of x264 (0.8M) ...
>  ERROR: missed type id 130179
>  ERROR: missed type id 131954
>  ERROR: missed type name (82925)
>  ERROR: missed type id 23828
>  ERROR: missed type id 132137
>  ERROR: missed type id 47285
>  ERROR: missed type id 47358
>  ERROR: missed type id 6333
>  ERROR: missed type id 134805
>  ERROR: missed type id 131958
>  ERROR: missed type id 134661
>  Compare ABIs of libx264.so.130 (2.3M) ...
>  ERROR: Failed to run ABI Compliance Checker (7)
>  Compare ABIs of libx26410b.so.130 (2.2M) ...
>  ERROR: Failed to run ABI Compliance Checker (7)
>  Compare ABIs of libx264.so.130 (2.4M) ...
>  ERROR: missed type id 36143
>  creating changes report ...
>  result: CHANGED (97.1%)
>  see detailed report:
>
>
> pkgdiff_reports/x264-debuginfo/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
>
>  
Readelf from elfutils reports "invalid DWARF" on libx264.so.130.debug:

$> eu-readelf --debug-dump=info libx264.so.130.debug

DWARF section [27] '.debug_info' at offset 0x50b:
  [Offset]
  Compilation unit at offset 0:
  Version: 4, Abbreviation section offset: 8442, Address size: 4, Offset 
size: 4
  [     b]  partial_unit
            stmt_list            (sec_offset) 0
            comp_dir             (form: 0x1f21) ???
eu-readelf: cannot get next DIE: invalid DWARF

Readelf from binutils reports:

$> readelf --debug-dump=info libx264.so.130.debug

Contents of the .debug_info section:

   Compilation Unit @ offset 0x0:
    Length:        0xba (32-bit)
    Version:       4
    Abbrev Offset: 8442
    Pointer Size:  4
  <0><b>: Abbrev Number: 105 (DW_TAG_partial_unit)
     <c>   DW_AT_stmt_list   : 0x0
readelf: Warning: Unrecognized form: 7969
     <10>   DW_AT_comp_dir    :
  <1><10>: Abbrev Number: 7566
readelf: Warning: DIE at offset 10 refers to abbreviation number 7566 
which does not exist

Why debug objects in x264-debuginfo package are invalid?

-- 
Andrey Ponomarenko, ROSA Lab.

[Sérgio Basto]

On Seg, 2013-07-15 at 15:16 +0400, Andrey Ponomarenko wrote: 
>  Sérgio Basto wrote:
>  > On Qui, 2013-07-11 at 12:49 +0400, Andrey Ponomarenko wrote:
>  >> Sérgio Basto wrote:
>  >>> On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:
>  >>>> Starting with 1.6 version of pkgdiff if you compare debug packages
>  >>>> and
>  >>>> add --details option on the command line then the tool will
>  >>>> automatically run abi-dumper to dump ABI of old and new shared
>  >>>> objects
>  >>>> found in the packages and then compare them by the
>  >>>> abi-compliance-checker tool.
>  >>> hum , so pkgdiff -details doesn't use abi-compliance-checker without
>  >>> abi-dumper installed ?
>  >> Yes, it doesn't. Detailed checks of ABI changes in shared objects will
>  >> be disabled in this case. They are enabled only if you install both
>  >> tools and compare appropriate debug-info RPM packages.
>  > ah ABI Status, just appears when we compare debuginfo packages (with
>  > -details )
>  >
>  >
>  >>>
>  >>> pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
>  >>> x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
>  >>> ERROR: cannot find ABI Dumper
>  >>> reading packages ...
>  >>> comparing packages ...
>  >>> creating changes report ...
>  >>> result: CHANGED (18.4%)
>  >>> see detailed report:
>  >>>
>  >>>
> pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
>  > Total Objects (with debug-info) 2
>  > ABI Compatibility 70.8%
>  >
>  >
>  > Cool thanks,
>  >
>  > pkgdiff print some errors [1] are you interested in reports ?
>  >
>  >
>  > [1] pkgdiff x264-debuginfo-0.130-3.20130502git1db4621.fc20.i686.rpm
>  > x264-debuginfo-0.133-1.20130709git585324f.fc20.i686.rpm -details
>  > reading packages ...
>  > comparing packages ...
>  > Compare ABIs of x264 (0.8M) ...
>  > ERROR: missed type id 130179
>  > ERROR: missed type id 131954
>  > ERROR: missed type name (82925)
>  > ERROR: missed type id 23828
>  > ERROR: missed type id 132137
>  > ERROR: missed type id 47285
>  > ERROR: missed type id 47358
>  > ERROR: missed type id 6333
>  > ERROR: missed type id 134805
>  > ERROR: missed type id 131958
>  > ERROR: missed type id 134661
>  > Compare ABIs of libx264.so.130 (2.3M) ...
>  > ERROR: Failed to run ABI Compliance Checker (7)
>  > Compare ABIs of libx26410b.so.130 (2.2M) ...
>  > ERROR: Failed to run ABI Compliance Checker (7)
>  > Compare ABIs of libx264.so.130 (2.4M) ...
>  > ERROR: missed type id 36143
>  > creating changes report ...
>  > result: CHANGED (97.1%)
>  > see detailed report:
>  >
>  >
> pkgdiff_reports/x264-debuginfo/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
>  >
>  >
>  
>  Readelf from elfutils reports "invalid DWARF" on libx264.so.130.debug:
>  
>  $> eu-readelf --debug-dump=info libx264.so.130.debug
>  
>  DWARF section [27] '.debug_info' at offset 0x50b:
>    [Offset]
>    Compilation unit at offset 0:
>    Version: 4, Abbreviation section offset: 8442, Address size: 4, Offset 
>  size: 4
>    [     b]  partial_unit
>              stmt_list            (sec_offset) 0
>              comp_dir             (form: 0x1f21) ???
>  eu-readelf: cannot get next DIE: invalid DWARF
>  
>  Readelf from binutils reports:
>  
>  $> readelf --debug-dump=info libx264.so.130.debug
>  
>  Contents of the .debug_info section:
>  
>     Compilation Unit @ offset 0x0:
>      Length:        0xba (32-bit)
>      Version:       4
>      Abbrev Offset: 8442
>      Pointer Size:  4
>    <0><b>: Abbrev Number: 105 (DW_TAG_partial_unit)
>       <c>   DW_AT_stmt_list   : 0x0
>  readelf: Warning: Unrecognized form: 7969
>       <10>   DW_AT_comp_dir    :
>    <1><10>: Abbrev Number: 7566
>  readelf: Warning: DIE at offset 10 refers to abbreviation number 7566 
>  which does not exist
>  
>  Why debug objects in x264-debuginfo package are invalid? 
I don't know , you tell me 

-- 
Sérgio M. B.

[Mathieu Bridon]

On Wed, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
>  If anyone is curious about it, I don't mind typing up the process
> I go
>  through to make the checks. I think I've found a pretty good path of least
>  resistance method :) 
I've never used it, but I'd certainly be interested in reading that if
you ever write it up. :)


-- 
Mathieu

[Richard Shaw]

On Wed, Jul 3, 2013 at 9:40 PM, Mathieu Bridon
<bochecha(a)fedoraproject.org&gt;wrote:

>  On Wed, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
>  > If anyone is curious about it, I don't mind typing up the process I go
>  > through to make the checks. I think I've found a pretty good path of
>  least
>  > resistance method :)
>
>  I've never used it, but I'd certainly be interested in reading that if
>  you ever write it up. :)
>  
I use a directory, abicompare in the home of my build user followed by the
library name then a version folder, i.e.:

~/abicompare/OpenImageIO/1.0.11
and
~/abicompare/OpenImageIO/1.0.13

Then I use a little scripe I wrote[1] to unpack the main library and devel
rpms into the version directory of each library because I can never
remember how to do it manually:

# cd ~/abicompare/OpenImageIO/1.0.11
# rpmunpack /path/to/rpms
(repeat for second version)

# abi-compliance-cheker -l OpenImageIO -dump 1.0.11/
(repeat for second version, the version as a directory works nicely because
it will assume that's the version of the library so no need to specify the
version manually)

# abi-compliance-checker -l OpenImageIO -old /path/to/abidump-1.0.11 -new
/path/to/abidump-1.0.13

Works like a charm as long as there's not any bad headers (like windows
only headers) installed. If that happens I usually just have to rm the
offending headers till I get a good dump.

Audrey,

How would this process change using abi-dump instead?

Thanks,
Richard

[1] rpmunpack contents:
#!/bin/bash

if [ ! -n "$1" ]
then
  echo "Unpacks an RPM into the current directory."
  echo ""
  echo "Usage: `basename $0` <package1> [package2]..."
fi

for file in $*; do
rpm2cpio $file | cpio -idmv
done

[Andrey Ponomarenko]

Richard Shaw wrote:
>  On Wed, Jul 3, 2013 at 9:40 PM, Mathieu Bridon 
>  <bochecha(a)fedoraproject.org <mailto:[e-mail]>> wrote:
>
>      On Wed, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
>      > If anyone is curious about it, I don't mind typing up the
>      process I go
>      > through to make the checks. I think I've found a pretty good
>      path of least
>      > resistance method :)
>
>      I've never used it, but I'd certainly be interested in reading that if
>      you ever write it up. :)
>
>
>  I use a directory, abicompare in the home of my build user followed by 
>  the library name then a version folder, i.e.:
>
>  ~/abicompare/OpenImageIO/1.0.11
>  and
>  ~/abicompare/OpenImageIO/1.0.13
>
>  Then I use a little scripe I wrote[1] to unpack the main library and 
>  devel rpms into the version directory of each library because I can 
>  never remember how to do it manually:
>
>  # cd ~/abicompare/OpenImageIO/1.0.11
>  # rpmunpack /path/to/rpms
>  (repeat for second version)
>
>  # abi-compliance-cheker -l OpenImageIO -dump 1.0.11/
>  (repeat for second version, the version as a directory works nicely 
>  because it will assume that's the version of the library so no need to 
>  specify the version manually)
>
>  # abi-compliance-checker -l OpenImageIO -old /path/to/abidump-1.0.11 
>  -new /path/to/abidump-1.0.13
>
>  Works like a charm as long as there's not any bad headers (like 
>  windows only headers) installed. If that happens I usually just have 
>  to rm the offending headers till I get a good dump.
>
>  Audrey,
>
>  How would this process change using abi-dump instead? 
The ABI dump should be created in the different way. Use "abi-dumper 
1.0.11/usr/lib/libopenImageio.so -o /path/to/abidump-1.0.11 -lver 
1.0.11" command instead of "abi-compliance-cheker -l OpenImageIO -dump 
1.0.11/" to create the ABI dump. Note that the library should be 
compiled with debug info, so you should extract and compare appropriate 
debug-info rpm packages instead of release ones. Otherwise the tool will 
report "can't find debug info in object(s)".

All of these steps are automated in the pkgdiff 1.6. Just compare 
debug-info rpm packages by this tool: pkgdiff --details 
libA-v1-debuginfo.rpm libA-v2-debuginfo.rpm, and see the output html report.

-- 
Andrey Ponomarenko, ROSA Lab.

[Richard Shaw]

Sounds like we need abi-dumper then... Anyone up for a review?

https://bugzilla.redhat.com/show_bug.cgi?id=980937

Thanks,
Richard

[Remi Collet]

Le 03/07/2013 22:03, Richard Shaw a écrit :
>  I initially got abi-compliance-checker into Fedora because one of my
>  packages does not maintain any sort of API/ABI compatibility or even
>  versioning for that matter. That way I could always check a new release
>  to see if any of its dependencies needed to be rebuilt.
>  
>  Since then, I've started using it for all of my libraries in the spirit
>  of "Trust but verify", and I've occasionally found issues even though
>  upstream didn't bump the soversion.
>  
>  So out of curiosity, anyone else using this great tool? 
I used it for some libraries I maintain.
http://rpms.famillecollet.com/compat_reports/

But I also use http://upstream-tracker.org/
Very usefull, except for not yet released version.

Remi

>  
>  If anyone is curious about it, I don't mind typing up the process I go
>  through to make the checks. I think I've found a pretty good path of
>  least resistance method :)
>  
>  Thanks,
>  Richard
>  
>

[Andrey Ponomarenko]

Remi Collet wrote:
>  But I also use http://upstream-tracker.org/
>  Very usefull, except for not yet released version.
>  
For some libraries we check unreleased versions from the upstream source 
control (git, svn, etc.). See example: 
http://upstream-tracker.org/versions/libssh.html

-- 
Andrey Ponomarenko, ROSA Lab.

[Laurent Rineau]

Le mercredi 03 juillet 2013 15:03:53 Richard Shaw a écrit :
>  I initially got abi-compliance-checker into Fedora because one of my
>  packages does not maintain any sort of API/ABI compatibility or even
>  versioning for that matter. That way I could always check a new release to
>  see if any of its dependencies needed to be rebuilt.
>  
>  Since then, I've started using it for all of my libraries in the spirit of
>  "Trust but verify", and I've occasionally found issues even though
> upstream
>  didn't bump the soversion.
>  
>  So out of curiosity, anyone else using this great tool? 
As the upstream release manager of the CGAL libraries (http://www.cgal.org/), 
I have started to use it for one year, to check before I publish a beta 
release.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau

[Petr Machata]

Richard Shaw <hobbes1069(a)gmail.com&gt; writes:

>  I initially got abi-compliance-checker into Fedora because one of my
>  packages does not maintain any sort of API/ABI compatibility or even
>  versioning for that matter. That way I could always check a new
>  release to see if any of its dependencies needed to be rebuilt. 
It would be nice to use this to decide that we don't need to rebuild
clients across Boost upgrades.  The trouble is that for this, more than
static Dwarf inspection is needed.  We also need an analysis of all
templates that haven't been instantiated, in case another library used
them in API.  This seems to call for a solution based on a GCC plugin or
something similar, where you really get to see and dump the source.

Thanks,
PM