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
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 ?
On Wed, Jul 3, 2013 at 4:33 PM, Sérgio Basto sergio@serjux.com 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
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_to...
Thanks, Richard
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_to...
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
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
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
IBook. 'Kiomjm Em 03/07/2013 19:00, "Xavier Bachelot" xavier@bachelot.org 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 .
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.
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 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
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 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?
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
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. :)
On Wed, Jul 3, 2013 at 9:40 PM, Mathieu Bridon bochecha@fedoraproject.orgwrote:
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
Richard Shaw wrote:
On Wed, Jul 3, 2013 at 9:40 PM, Mathieu Bridon <bochecha@fedoraproject.org mailto:bochecha@fedoraproject.org> 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.
Sounds like we need abi-dumper then... Anyone up for a review?
https://bugzilla.redhat.com/show_bug.cgi?id=980937
Thanks, Richard
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
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
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.
Richard Shaw hobbes1069@gmail.com 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